With static routing, you can route traffic from a subnet to the specified IP address ranges through the VMs specified as the next hop.
Routing is based on route tables. The tables contain static routes consisting of the target subnet's prefix in CIDR notation and the internal IP address of the next hop.
Route tables are linked to a subnet and can't contain duplicate prefixes. Traffic from the subnet with the linked table is routed to the prefixes specified in the routes through the appropriate next hop addresses.
You can also use the prefix
0.0.0.0/0 in routes. This means that all traffic, if it's not sent via other routes, is routed through the next hop specified for the prefix
For example, a subnet with CIDR
10.1.0.0/24 has a linked route table with the following routes:
In this case, all traffic to subnet
192.168.0.0/16, which is located in a different virtual network, is routed through the VM with the address
10.1.0.5. All other traffic is routed through the VM with the address
10.1.0.10. Note that overriding the route for prefix
0.0.0.0/0 may affect the external availability of the VM from the subnet with the table that contains this route.
You currently can't use prefixes from address ranges that are allocated to subnets within a virtual network. Only destination prefixes outside the virtual network are supported, such as subnet prefixes from another Yandex.Cloud network or your local network.
When creating a route, you can set an unused internal IP that isn't linked to a VM as the next hop. In this case, the route is only used after you run a VM with the appropriate IP address.
The two main uses of static route in Yandex.Cloud:
- Building a network route to the appropriate subnet through a single VM. The internal IP address is used as the VM ID. For more information about building network routes in Yandex.Cloud and other virtual or local networks, see the tutorials Routing through a NAT instance and Creating an IPSec VPN tunnel.
- A fail-safe routing scheme with routes in multiple availability zones. You can create VMs in different availability zones and route them to the same destination subnet. Note that different route tables should be linked to subnets in different availability zones, since you can't place routes to the same prefixes in the same table. If a VM in one of the availability zones fails, VMs from the other zones will remain linked to the destination subnet.
Rerouting traffic to the internet
If the destination prefix of a route from the route table is specified as an internet address prefix, access to and from such addresses via the VM's public IPs from the subnets that this table is linked to is disabled.
For example, let's say there's a VM named
vm-1 with a public IP address connected to the
my-subnet subnet. If you link a table named
my-route-table with a route for the prefix
0.0.0.0/0 (all addresses) via the next hop
10.0.0.5 to the
my-subnet subnet, then access via the
vm-1 public address is disabled. This happens because all traffic to and from the
my-subnet subnet is now routed via the next hop address.
To keep cloud resources available from a public address, you can:
- Move resources with public IPs to a separate subnet.
- Instead of configuring a route to the internet, enable internet access for the subnet via a NAT. The feature is at the preview stage and can be provided by technical support upon request.