At site A, the gateway rewrites source addresses of the form 192.168.10.x to for outgoing traffic, and does the reverse translation on destination addresses (from.
In the other direction (lower part of the diagram), the same tricks are applied in reverse so at the end the host at site A thinks it's really talking to 192.168.200.211, and the host at site B thinks it's really talking to 192.168.100.44.Īll the logic is implemented in the gateways. Once that is done, the target host receives the packet and thinks it's from 192.168.100.44. When gateway gwb receives it, it has to change the destination address to the real one of the receiving host, that is, 192.168.10.211. Gateway gwa, before forwarding the packet to the VPN link, rewrites the source address so it looks like the packet is coming from 192.168.100.44 instead (192.168.100.0/24 is the fake IP range assigned to site A). The diagram below illustrates what needs to be done. More generally, packets coming from site A's host 192.168.10.y will appear at site B as if they're coming from host (where y is the same in both addresses). More generally, a host at site A wanting to talk to host 192.168.10.x at site B, will instead use a destination address of (where x is the same in both addresses).Īssuming we're somehow able to deliver those packets to site B (see later), something has to happen in between so the host at site B thinks the packets are destined to it, and they should look like they're coming from an IP range different from its own (the fake range assigned to site A, 192.168.100.0/24). So if our host 192.168.10.44 at site A wants to talk to host 192.168.10.211 at site B, it will pretend it wants to talk to host 192.168.200.211 instead. The idea is: to each site, the other site will appear as if it is using some other, fake, IP range.
IPTABLES NETMAP DNAT FULL
One may think of doing some sort of 1:1 NAT, also known as full cone NAT (here even without port number translation).
Of course, renumbering is out of the question, so the poor sysadmin has to come up with some klu ^Wbrilliant solution to solve the routing problem and save the day. Connections can be in either direction, and potentially any host at any site should be able to talk to any host or hosts at the other site. Site A and site B both use the same IP range (192.168.10.0/24), and now for whatever reason the two sites need to talk to each other (for example through a VPN).
Life is unfair and shit happens, so let's consider the situation in the diagram:
0 kommentar(er)
