Cheat sheet for IP forwarding to the internal network without a bridge and iptables in 4 commands

The article will discuss the routing of the external IP address inside the local one without forwarding the ethernet gateway and rewriting the addresses in iptables. As a result, there will be one correct external IP address on the internal server's network card; there will be no internal IP addresses.


Application practice: for example, routing IP addresses from server to virtual machines, without the need to connect them to the ethernet network of a physical server.
At the same time, the network interface can be assigned both a network of addresses and disparate addresses with which this server is listed simply as the next routing node (for example, Hetzner distributes its fault-tolerant IP addresses).

The initial state

S0 server 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 server S0, does not participate in the configuration.
1.2.3.4 - external IP-address, packages of which come to eth0 and which need to be transferred to the internal server
192.168.0.1 - IP address of the S0 server on brLAN.
IPv4 redirection enabled on S0

')
S1 server - a server on the internal network or a virtual server, for which you need to forward an external IP address, it has one network interface - eth0, included in brLAN.

iptables on both servers is disabled

Brief cheat sheet for teams

S0 server (gateway):

 ip route add 1.2.3.4 dev brLAN #     1.2.3.4   brLAN 

S1 server (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: you do not need to assign internal IP addresses for S1 - the packets are immediately sent from the public address.

Configuring the client through configs

On the client side, these rules can be configured through the configuration files and the settings will be raised immediately with the network interface, as is usually the case.


How to configure the server through the configs has not yet found, but in general it is a lesser problem - one gateway is simple to control and elementary setup - just for each address (network of addresses) to call the command to send traffic to the internal network - this can be done with a script and included in autoload .

Advantages over iptables with forwarding to internal IP

1. The destination address of the packet is saved.
2. The correct external IP is visible on the internal server interface
3. There is no need to follow iptables mirror rules - so that outgoing traffic also comes from the correct IP
4. If it is necessary to filter traffic on the gateway, the rules will look clearer - point to the real server address
5. There is no need to maintain an internal addressing system.
6. Easier to manipulate routes from scripts
7. With the growth of infrastructure, it will be possible to switch to dynamic routing while preserving the already existing rules and logic of operation.
8. 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. Maybe there are some other details.
9. More clearly, ip route routing output immediately shows what traffic will go to the internal network, iptables would have a lot more rules + filter rules and output needed to be parsed separately
10. Two servers from brLAN can communicate with each other at public addresses directly, without the participation of the 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 </spoiler> 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 indicate instead any IP address of the gateway server, for example, its public IP, then the path tracing will look beautiful. With the default settings, everything will work, but there may be some nuances.

For example, the ability to respond to its 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 has moved to another physical server), you will need to change the settings of the internal server. When using a separate gateway address common to all such gateways, this problem does not arise.