ipsec vpn

第二个问题隧道如何建立

解决了Ip地址动态寻址的问题，现在来说一下Nat穿越的问题。我们知道，Udp和TCP是可以穿越防火墙的。直接的IPsec封装，不能穿越防火墙，因为防火墙需要更改端口信息，这样回来的数据包，才能转到正确的内部主机。用UDP显然比较合适，因为使用tcp的话，不仅三次握手占据时间很长，而且还有来回的确认。而实际上，这些工作属于ipsec内部封装的报文要干的事情，放在这里完成是不合适的。因此，用udp来封装ipsec报文，以穿越nat，几乎是唯一可以选择的方案。

用udp穿越nat防火墙，这只解决了问题的一半，因为这要求至少有一方处于Internet公网上面。有可路由的IP地址。而有时会发生两个vpn节点都在nat之后的情景，这只能通过第三方转发来完成。即两个设备都可以与第三方设备互通，第三方设备为双方进行转发。这个可以通过之前的模型解析，老张老李不能直接通讯，他们都可以与老王通讯，老王就可以在中间进行转发。凡是小李小张的通讯，交给他们老爸以后，老王最后再进行转交。这是隧道路由的概念就很清晰了，不能一个隧道直接到达，可以在几个隧道之间转发。

所以，IPsec vpn并不神秘。所有核心的工作无非就是围绕以下几个方面展开:

如何找到与本VPN节点相关的其他节点。

协商出一个可以通讯的隧道。如果是nat之后，应该怎么处理。

建立隧道路由表，确定不同的目标地址，走不同的隧道。

假定以上的问题都得到了解决，通过某种方式，动态IP地址的VPN节点可以相互找到对方，并且能够建立隧道，因此也能够实现隧道路由通讯。是不是一个完整的VPN就能够实现了呢??

答案仍然是否，解决了以上问题，并不代表一个很好用的VPN产品，仍然有其他很多问题。之后的问题是围绕着复杂性展开的，简单的原理实现之后，剩下的工作就是要解决掉全部相关的边缘问题。才能够实现一个好用的东西。能够用是一回事，好用是另外一回事。

IPSEC VPN配置:

IP SEC Tunnel 示意图

mohe:

crypto isakmp policy 10

encr 3des

authentication pre-share