Multihome IPv4 on Linux
Content: how to make the computer respond on the Internet to all its IP-addresses on all its interfaces, each of which has a default gateway. Applies to servers and desktops.
Keywords: policy routing, source based routing
Lyrics: There are enough articles about policy routing in Linux. But they most often deal with common, more subtle and complex cases. I will analyze the trivial scenario of the following form:
')
Our computer (server) has three interfaces. On each interface, the gateway gave him IP (static or dhcp, it doesn't matter) and said “all traffic went to me”.
If we leave this configuration as it is, then the principle of "who was the last one to get up, and the default gateway" will be used. In the picture above, if the bottom interface (241) rises last, all traffic will be sent to it. If a request to the first interface (188) comes to our server, then the answer to it will still go down. If the router / provider has at least minimal protection against forgery of addresses, then the answer is simply dropped as invalid (from the point of view of 241.241.241.1 it was sent a packet from src 188.188.188.188 from the network 241.241.241.0/24, which, obviously, must).
In other words, in the normal version only one interface will work. To make the situation worse, if the addresses are received via dhcp, then the lease update on other interfaces can overwrite the default gateway, which means that the interface that worked, will stop working, and another interface will start to work. Successful stable operation of your server, so to speak.
The overall solution is policy routing. Quite a voluminous and interesting thing that allows you to make all kinds of miracles. Of these miracles, we (in the framework of this article) will leave only one thing: “send traffic to each router from its“ interface ”. That is the classic source-based routing in the most primitive form.
Overview of the solution from the height of bird flight:
We set three routing options for the traffic: “everything in eth0”, “everything in eth1”, “everything in eth2”, further formulate the rules: send traffic from the IP of the first interface through the first option, traffic from the second IP through the second option, the third IP - through the third.
As a result, we get the following construction:
Summary:
The ip utility (its official name is iproute2) has a special command - ip rule to manage policy routing. And adding routes (ip route add) can take an argument with the name of the table. The kernel does not know anything about the names of the tables, but iproute2 requires the use of the name from its config -
We will call our routing tables eth0-route, eth1-route, eth2-route. Take the random symbolic numbers - 100, 101, 102.
For each table we will set the default route (it is possible and not the default - the fantasy is in your hands). These rules will not break anything on the server and you can do them live. Until we say to use these tables, these are just Baitics in memory and they do not affect the routing operation (that is, we will not suddenly stay without connection in the middle of the process).
Now the intimate moment: carefully read the written. After enabling the rules, a typo in the table can leave the server without connectivity.
Everything. From this point on, the server will begin to respond to all three addresses. Good news: policy routing has a higher priority than the default route dhcp, so the lease update will not break the routing.
Unpleasant news: if you renew your rent, you will be given another address, then it will stop working. This can be corrected either by making a rule with a mask (
(debian / ubuntu)
A great place for these rules is in / etc / network / interfaces. For the desired interface, we write:
Routing note: source routing generally opens a vulnerability in the system (a packet with a fake source is sent to you, and you pass it on, as if it should be), but this visibility level is directly connected. In addition, if you are limited to only your address in the rules, then Linux will not miss this, plus you need to have routing enabled. On a regular server, such a configuration is completely safe and fairly reliable.
Note on load-balancing: By registering all three addresses in the A-record DNS zones, you get a free round-robin on all three interfaces without bonding and poetess. Since they will be processed by the same server and the same application, this will allow even stateful sessions to be balanced.
Keywords: policy routing, source based routing
Lyrics: There are enough articles about policy routing in Linux. But they most often deal with common, more subtle and complex cases. I will analyze the trivial scenario of the following form:
')
Our computer (server) has three interfaces. On each interface, the gateway gave him IP (static or dhcp, it doesn't matter) and said “all traffic went to me”.
If we leave this configuration as it is, then the principle of "who was the last one to get up, and the default gateway" will be used. In the picture above, if the bottom interface (241) rises last, all traffic will be sent to it. If a request to the first interface (188) comes to our server, then the answer to it will still go down. If the router / provider has at least minimal protection against forgery of addresses, then the answer is simply dropped as invalid (from the point of view of 241.241.241.1 it was sent a packet from src 188.188.188.188 from the network 241.241.241.0/24, which, obviously, must).
In other words, in the normal version only one interface will work. To make the situation worse, if the addresses are received via dhcp, then the lease update on other interfaces can overwrite the default gateway, which means that the interface that worked, will stop working, and another interface will start to work. Successful stable operation of your server, so to speak.
Decision
The overall solution is policy routing. Quite a voluminous and interesting thing that allows you to make all kinds of miracles. Of these miracles, we (in the framework of this article) will leave only one thing: “send traffic to each router from its“ interface ”. That is the classic source-based routing in the most primitive form.
Overview of the solution from the height of bird flight:
We set three routing options for the traffic: “everything in eth0”, “everything in eth1”, “everything in eth2”, further formulate the rules: send traffic from the IP of the first interface through the first option, traffic from the second IP through the second option, the third IP - through the third.
As a result, we get the following construction:
| source: 188.188.188.188 | to eth0-route table | default via 188.188.1 | via eth0 |
| source: 75.75.75.75 | to eth1-route table | default via 75.75.75.1 | via eth1 |
| source: 241.241.241.241 | to eth2-route table | default via 241.241.241.1 | via eth2 |
Summary:
- Configure the iproute2 utility using the config (all of a sudden, it has a config!) - give the names to three routing tables
- Configure routes in three routing tables - more precisely, set default scales
- Specify the rules by which traffic will be distributed across the three route tables
Steps more
The ip utility (its official name is iproute2) has a special command - ip rule to manage policy routing. And adding routes (ip route add) can take an argument with the name of the table. The kernel does not know anything about the names of the tables, but iproute2 requires the use of the name from its config -
/etc/iproute2/rt_tables (which matches names to abstract numbers that the kernel understands). Values of “0” and values below 255 (254, 253) are occupied, the rest can be used.Iroute2 setup
We will call our routing tables eth0-route, eth1-route, eth2-route. Take the random symbolic numbers - 100, 101, 102.
echo 100 eth0-route >> / etc / iproute2 / rt_tables echo 101 eth1-route >> / etc / iproute2 / rt_tables echo 102 eth2-route >> / etc / iproute2 / rt_tables
Configuring routes in three routing tables
For each table we will set the default route (it is possible and not the default - the fantasy is in your hands). These rules will not break anything on the server and you can do them live. Until we say to use these tables, these are just Baitics in memory and they do not affect the routing operation (that is, we will not suddenly stay without connection in the middle of the process).
ip route add default via 188.188.188.1 dev eth0 table eth0-route ip route add default via 75.75.75.1 dev eth1 table eth1-route ip route add default via 241.241.241.1 dev eth2 table eth2-route
Now the intimate moment: carefully read the written. After enabling the rules, a typo in the table can leave the server without connectivity.
Enable policy routing
ip rule add from 188.188.188.188 lookup eth0-route ip rule add from 75.75.75.75 lookup eth1-route ip rule add from 241.241.241.241 lookup eth2-route
Everything. From this point on, the server will begin to respond to all three addresses. Good news: policy routing has a higher priority than the default route dhcp, so the lease update will not break the routing.
Unpleasant news: if you renew your rent, you will be given another address, then it will stop working. This can be corrected either by making a rule with a mask (
from 241.241.241.0/24 ), or by nailing the address with nails in the dhcp-server config (in general, servers are not allowed to issue dynamic addresses via DHCP ...)Cast in configs
(debian / ubuntu)
A great place for these rules is in / etc / network / interfaces. For the desired interface, we write:
iface eth0 inet static
address 188.188.188.188
netmask 255.255.255.0
broadcast: 188.188.188.255
post-up ip route add default via 188.188.188.1 dev eth0 table eth0-route
post-up ip rule add from 188.188.188.188 lookup eth0-route
Notes
Routing note: source routing generally opens a vulnerability in the system (a packet with a fake source is sent to you, and you pass it on, as if it should be), but this visibility level is directly connected. In addition, if you are limited to only your address in the rules, then Linux will not miss this, plus you need to have routing enabled. On a regular server, such a configuration is completely safe and fairly reliable.
Note on load-balancing: By registering all three addresses in the A-record DNS zones, you get a free round-robin on all three interfaces without bonding and poetess. Since they will be processed by the same server and the same application, this will allow even stateful sessions to be balanced.
Source: https://habr.com/ru/post/107267/
All Articles