Cheat sheet for forwarding IP to the internal network without a bridge and iptables in 4 teams
- Tutorial
This article will discuss the routing of an external IP address into a local one without forwarding an ethernet gateway and rewriting addresses in iptables. As a result, there will be one correct external IP address on the network card of the internal server, there will be no internal IP addresses.
Application practice: for example, routing IP addresses from a server to virtual machines, without the need to connect them to the ethernet network of a physical server.
At the same time, both a network of addresses and disparate addresses can be assigned to the network interface, for which this server is indicated simply as the next routing node (for example, Hetzner distributes its fault-tolerant IP addresses).
Server S0 is a gateway to the Internet, it has two eth0 network cards - external and brLAN - internal (this can be either a physical card or just a bridge for networking with virtual machines).
1.1.1.1 - the external IP address of the S0 server, is not involved in the configuration in any way.
1.2.3.4 - the external IP address, packets of which arrive at eth0 and which must be forwarded to the internal server
192.168.0.1 - the IP address of the S0 server on brLAN.
IPv4 redirection enabled on S0
Server S1 - a server on the internal network or a virtual server for which you need to forward the external IP address; it has one network interface - eth0, which is included in brLAN.
iptables on both servers is turned off
Server S0 (gateway):
Server S1 (internal)
That's all: for S1, you do not need to assign internal IP addresses - packets are immediately sent from the public address.
On the client side, these rules can be configured through configuration files and settings will be raised immediately along with the network interface, as usually happens.
I haven’t found the server through the configs yet, but in general it’s a smaller problem - it’s easy to control one gateway and the configuration is simple - just call the command for sending traffic to the internal network for each address (network of addresses) - this can be done at least with a script and included in startup .
PS, in principle, the address 192.168.0.1 can also be excluded and instead of it you can specify any IP address of the gateway server, for example, its public IP, then the trace of the path will look beautiful. In the default settings, everything will work, but nuances may arise.
For example, the ability to respond to their IP addresses from any interface can sometimes interfere and should be turned off. Or if the public IP address of the gateway changes (for example, the virtual machine has moved to another physical server), you will need to change the settings of the internal server. When using a separate address common for all such gateways for a gateway, this problem does not arise.
Application practice: for example, routing IP addresses from a server to virtual machines, without the need to connect them to the ethernet network of a physical server.
At the same time, both a network of addresses and disparate addresses can be assigned to the network interface, for which this server is indicated simply as the next routing node (for example, Hetzner distributes its fault-tolerant IP addresses).
The initial state
Server S0 is a gateway to the Internet, it has two eth0 network cards - external and brLAN - internal (this can be either a physical card or just a bridge for networking with virtual machines).
1.1.1.1 - the external IP address of the S0 server, is not involved in the configuration in any way.
1.2.3.4 - the external IP address, packets of which arrive at eth0 and which must be forwarded to the internal server
192.168.0.1 - the IP address of the S0 server on brLAN.
IPv4 redirection enabled on S0
Hidden text
cat /etc/sysctl.conf | grep net.ipv4.ip_forward
net.ipv4.ip_forward=1
Server S1 - a server on the internal network or a virtual server for which you need to forward the external IP address; it has one network interface - eth0, which is included in brLAN.
iptables on both servers is turned off
Brief cheat sheet for teams
Server S0 (gateway):
ip route add 1.2.3.4 dev brLAN # отправлять пакеты для адреса 1.2.3.4 на интерфейс brLAN
Server S1 (internal)
ip addr add 1.2.3.4 dev eth0 # Добавить адрес 1.2.3.4 на интерфейс, смотрящий в brLAN
ip route add 192.168.0.1 dev eth0 # Пакеты на 192.168.0.1 отправлять в сеть brLAN
ip route add default via 192.168.0.1 # Весь внешний трафик отправлять через 192.168.0.1
That's all: for S1, you do not need to assign internal IP addresses - packets are immediately sent from the public address.
Configuring the client through configs
On the client side, these rules can be configured through configuration files and settings will be raised immediately along with the network interface, as usually happens.
Example configuration files for centos 6.5
cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=1.2.3.4
NETMASK=255.255.255.255
SCOPE="peer 192.168.0.1"
cat /etc/sysconfig/network-scripts/route-eth0
ADDRESS0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY0=192.168.0.1
I haven’t found the server through the configs yet, but in general it’s a smaller problem - it’s easy to control one gateway and the configuration is simple - just call the command for sending traffic to the internal network for each address (network of addresses) - this can be done at least with a script and included in startup .
Advantages over iptables with forward to internal IP
- The destination address of the packet is saved.
- The correct external IP is visible on the internal server interface
- There is no need to follow the iptables mirrored rules - so that outgoing traffic also came from the correct IP
- If you need to filter traffic on the gateway, the rules will look more clearly - point to the real server address
- There is no need to maintain an internal addressing system
- Easier to manipulate routes from scripts
- With the growth of infrastructure, it will be possible to switch to dynamic routing while maintaining existing rules and logic of work
- The ability to access servers at a public address regardless of the source of traffic. For iptables, in this case, you would have to configure the rules separately for cases when the source of traffic on the gateway, from the internal network, from the external network. Perhaps there are some more subtleties
- The visual conclusion of routing on ip route immediately shows what traffic will go to the internal network, in iptables there would be much more rules + there would be filtering rules and the output needs to be separately analyzed
- Two brLAN servers can communicate with each other at public addresses directly, without a gateway Hidden text
ping 1.2.3.4 PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data. 64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=1.18 ms From 192.168.122.1: icmp_seq=2 Redirect Host(New nexthop: 1.2.3.4) 64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=0.386 ms 64 bytes from 1.2.3.4: icmp_seq=3 ttl=64 time=0.325 ms 64 bytes from 1.2.3.4: icmp_seq=4 ttl=64 time=0.262 ms 64 bytes from 1.2.3.4: icmp_seq=5 ttl=64 time=0.298 ms 64 bytes from 1.2.3.4: icmp_seq=6 ttl=64 time=0.344 ms arp Address HWtype HWaddress Flags Mask Iface 192.168.122.1 ether 52:54:00:91:b2:67 C eth0 1.2.3.4 ether 52:54:00:11:80:37 C eth0
How to get rid of 192.168.0.1
PS, in principle, the address 192.168.0.1 can also be excluded and instead of it you can specify any IP address of the gateway server, for example, its public IP, then the trace of the path will look beautiful. In the default settings, everything will work, but nuances may arise.
For example, the ability to respond to their IP addresses from any interface can sometimes interfere and should be turned off. Or if the public IP address of the gateway changes (for example, the virtual machine has moved to another physical server), you will need to change the settings of the internal server. When using a separate address common for all such gateways for a gateway, this problem does not arise.