一个VPN客户端的路由故障解决及深入探讨
一个VPN客户端的路由故障解决及深入探讨
使用VPN 客户端远程访问过公司内网的朋友一定有过这种经验，就是当你VPN连接成功之后，能够访问公司内网却再也不能访问Internet了，显然这 是一个路由上的问题，因为VPN 客户端是通过Internet连接到VPN服务器的，也就是说Internet实际是可达的，但VPN连接建立后就不能 访问了，说明路由表有了变化，导致出现了上面的问题。很多人都是通过取消“在远程网络上使用默认网关”选项来解决这个问题的（这个选项在VPN连接的 TCP/IP属性中，如图1），这种解决方法可行吗？是最好的方法吗？也许你很奇怪，这有什么不行的，还会有其他问题？确实如此，因为这样可能解决了一个 路由问题，却可能带来新的路由问题，更严重的是，还可能带来安全问题，本来采用VPN就是为了保证安全，结果却可能因为它而让你失去安全，所以千万不要小 看这一条设置，不然，微软又何必吃力不讨好地在这里放上你认为是“画蛇添足”的一个选项呢？那怎样才是更好更安全的解决方法呢？要回答这个问题，需要先对 VPN 客户端的路由有一个深入的了解，从哪里开始呢？既然是这个问题引起的，那就从刚才这个问题谈起吧。 



 
既 然我们认定是路由问题，那么就可以从VPN连接前后路由表的变化出证据来，首先在VPN没连接之前，用route print命令输出当前的路由表项， 然后连接上VPN（这里不取消图1的选项），再次运行route print命令，比较前后两次命令的区别，从中可以看出，连接后多出了几条路由，其中比 较重要的有两条（图2中画红线的）：




一条是（这里称之为route1）
0.0.0.0          0.0.0.0      150.0.1.226     150.0.1.226       1
一条是（这里称之为route2）
218.70.201.62  255.255.255.255       150.0.1.43      150.0.1.41       20
其 中的150.0.1.226是VPN客户端从VPN服务器上获得的IP地址，而150.0.1.41是本机网卡的地址，而218.70.201.62是 VPN服务器的公网地址。从图2还可以看出，原先默认路由的
metric值增加了且高于新的默认路由（route1），这样实际上原先的默认路由已不起作 用了，起作用的是新的默认路由，因为它的metric值更低，这样到Internet的访问就使用了新的默认路由，而这条路由是把数据包交给VPN的虚拟 接口处理的，而VPN虚拟接口的数据最终会发送到远方的VPN服务器（route2），所以这样通常情况下就不能访问Internet上的其他站点了，这 就是为什么VPN连接后不能访问Internet的原因。
上面只是简单的说明了为什么VPN连接后不能访问Internet的原因，但还有更多的 细节需要我们去了解，下面来看看VPN客户端的路由决策及数据报封装的过程。众所周知，VPN就是虚拟的点对点链路，这个VPN虚拟接口也就是一个虚拟的 点对点链路接口（从图2也可以看出，VPN连接成功后在Interface list中多出了一个WAN(PPP/SLIP) 接口，这就是一个虚拟的 VPN点对点链路接口），当VPN虚拟接口收到数据包时，由于这个虚拟接口是一个虚拟的点对点接口，所以它将把从网络层得到的数据包封装成PPP点对点数 据帧并进行加密等操作，然后把它送到网关(route1指出)，而这里的网关正是VPN客户端自己，所以这个被封装的PPP点对点数据帧又被返回给本机再 次处理，这次处理其实就是再次封装的过程，为什么要再次封装，上面第一次封装好以后送上网络不就行了吗？这是因为第一次封装的帧只能通过虚拟的VPN接 口，而要把数据通过实际的接口进行传输，还必须在实际的
链路层上进行再次封装才行。而在最终封装成链路层数据帧之前，其实需要对第一次封装成的PPP数据 帧进行其他的多级封装，因为规范中是不能直接把PPP怎样设置代理服务器帧封装在另一个链路层帧中的，需要在它们之间添加一些报头（实际上最简单的PPTP封装就是在PPP 帧前添加了一个GRE头和IP头，如图3，深部分加上前面的PPP报头是第一次VPN虚拟接口封装的，GRE和IP头是后来多级封装的），在封装到网络 层比如IP报头的时候，又需要进行路由决策了，由于这个数据包要明确地发送到远方的VPN服务器，所以它将寻一条到达远方VPN服务器的路由，由于在 VPN连接建立时就同时创建了一条到达VPN服务器的路由（route2），于是再次封装成PPTP格式或L2TP格式的IP数据报将交由这条路由所指定 的接口进行处理，如果是以太网接口，这个数据报就加上以太网报头，如果是点对点，就加上点对点链路报头，然后发送到物理网络上，在这里，由于route2 所指定的接口是150.0.1.41，也就是网卡接口，所以它将加上以太网帧头，然后发送到物理网络上去。




从 上面我们可以得出一点，要使用VPN连接，必须让需要通过VPN连接传输的数据包先到达VPN虚拟接口进行“处理”，如果绕过了VPN虚拟接口，那么你这 个VPN连接就不是真正的“VPN”了，因为这样的数据包是没经过加密等措施就直接发送到了Internet上，所以你的安全性根本就没得到保证。开篇我 们不是说了当取消了图1中的“在远程网络上使用默认网关”选项可能带来新的路由问题和安全问题吗？这里就来看看，仍然在VPN连接后看看此时VPN客户端 的路由表，如图4：




 
从上面可以看出，默认路由没有变，而添加了一条VPN虚拟接口IP对应的分类网络路由条目：
150.0.0.0      255.255.0.0      150.0.1.226     150.0.1.226       1
假 定我现在要通过VPN连接访问远程公司内网的192.168.0.0/24子网，根据上面的路由表，
匹配的路由只有第一条默认路由，但默认路由是通过本地 网卡到达网关后直接发送到192.168.0.0/24去的，很显然这个目的地是不能到达的，因为这是一个私有网络，因特网上的路由器不会转发到达此类网 络的数据包，从另一方面说，如果你的远程子网能够通过Internet到达，但由于绕过了VPN虚拟接口，数据是没有加密的，所以不能保证数据的安全性， 这并不是真正的VPN。但如果是选中了“在远程网络上使用默认网关”选项，同样是采用默认路由（图2中），却不会出现上面的路由问题和安全问题。有的朋友 可能要说了，为什么不为你的VPN客户端分配192.168.0.0/24子网的IP呢？这样取消图1的选项不也行吗?我先不回答对与否，先假设VPN客 户端也正位于一个192.168.0.0/24网络中，情况将会怎样呢？很显然根据前面的路由表，又会出现路由问题，所有发送到本地子网的数据包将被路由 到远程子网中，而如果是没有取消这个选项，那么发送到远程子网的数据也不可能到达，因为它们直接发送到了本地的子网中。所以为了避免客户端的这种路由问 题，我们为VPN客户端分配IP范围时不要与客户端所处的网络范围相同，以免出现问题。
那怎样来解决这个问题呢？取消这个选项又不能保证安全性且 可能带来新的路由问题，而不取消这个选项又不能同时上网？这确实是一个两难的决策，而且不同的网络环境可能有不同的解决方法，没有一个统一的设置。总的来 说，由于取消图1的选项可能导致安全问
题，所以尽量不要取消他它，对于那些既想通过VPN连接访问远程内网又想访问Internet的用户可以采用这样一 种方法，就是配置它们使用代理访问Internet，比如设置它们使用HTTP代理或Socks代理，这两项功能是现今大多数代理服务器都提供的；如果 VPN客户端的IP与VPN服务器内网卡位于同一个逻辑子网，且只访问这个逻辑子网时，并且不与本地连接的网络属于同一个逻辑子网时，就可以取消图1的选 项。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。