|
此文章由 richsea 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 richsea 所有!转贴必须注明作者、出处和本声明,并保持内容完整
Because both networks use the same internal IP addressing, it is not possible to simply build a
tunnel between the two sites. However, if the tunnel endpoints on both sides are Juniper services routers, it
is possible to configure a tunnel between these sites with an advanced configuration using NAT. It is
important to understand this basic routing dilemma. If a host is attached to a network, say 10.0.0.0/24, and
the other device on the remote end is attached to a network using the same IP address subnet, it is not
possible to build a tunnel and route the traffic to the other device without some sort of address translation.
This is because all packets are routed based on the destination IP address. Before routing occurs, a
determination must be made as to whether the destination IP is on the same (local) network or not. If the
destination IP is on the same network, say 10.0.0.10, the destination device is found using Address
Resolution Protocol (ARP). However, if the destination IP resides on a different network, the packet is sent
to the next- hop router based on the device's routing table. Because both the local and remote networks
share the same IP addressing scheme, the packets will be handled locally and never route to the VPN
tunnel. To work around this, we can perform static NAT on the source IP and destination IP of all traffic
destined for the remote network at the other end of the tunnel. For this reason, aroute based approach to
IPsec VPNs makes sense, because the creation of a "virtual" network interface on each services router by
way of a "secure tunnel" or "st0" interface is required. It is important to note that in this case the both source
and destination addresses are translated as the packet traverses the VPN tunnel to the end host. Thus the
services routers at each end of the tunnel must contact each other using a newly created IP network. |
评分
-
查看全部评分
|