如何为VPN端点本身必须能够联系远程networking的IPSec VPNbuild立路由
我有一个IPSec VPN的问题相同的情况：stream量路由不正确 （但我似乎无法直接联系该用户，我也不能对这个问题发表评论 – 没有人回答过）。
我也有一台Windows 2008 R2服务器，IPSec VPN直接在服务器上结束。
服务器有一个单一的networking接口，它有一个公共IP地址（例如，我们称之为203.10.10.10）。
我希望远程专用networking（10.16.0.0/255.254.0.0）上的计算机能够连接到该服务器上的IPSec隧道末端的私有IP地址上的Windows服务器（而不是路由器在服务器前面）。
同样重要的是（这可能是困难之处），我需要服务器能够通过TCP连接到远程（10.16.0.0）networking上的设备（例如通过HTTP下载图像）。
以下是它的样子：
我为服务器select的私有IP为192.168.70.1/255.255.255.0，并且build立到远程专用networking的隧道的IPSecfilter用于源/目的地192.168.70.0/24和10.16.0.0/15。
如果我从Windows服务器ping远程networking上的一个地址，设置source参数，那么我可以build立隧道并且ping将工作（即ping -S 192.168.70.1 10.16.0.1 ）。
但是，任何发送到10.16.xx地址的“正常”stream量（包括源地址强制为192.168.70.1的ping）都会通过默认路由愉快地发送到Internet，并且不会启动或进入隧道。
题
这样的设置甚至可能吗？ 还是不可能让VPN端点自己发送数据在隧道上，从它的一个私人地址发出？ （VPN端点是否必须位于通过隧道发送数据的设备的单独路由器上？）
如何设置Windows Server以确保与10.16.0.0networking的所有通信都将从其私有IP地址发出。
私人地址不一定是192.168.70.1 – 如果有必要可以select另一个子网（我这样说是因为我已经读过了，其他所有的东西都是相同的，Windows Vista将会使用最接近匹配的原始IP目的地 – 所以也许使用10.XXX IP作为服务器的私有地址会有帮助？）
我不能很容易地testing，因为这个VPN隧道的另一端不在我的控制之下 – 如果我select更改192.168.70.1地址，我需要另一端的networking工程师进行configuration更改。
额外的信息：我曾经试过甚么
我尝试了两种设置私有IP地址的方法（在Windows服务器上），试图使数据包正确路由并满足build立隧道的IPSec规则。
主界面上的私人地址
通过将192.168.70.1地址添加到主networking接口（除了公用IP）之外，似乎不可能定义到10.16.0.0的任何路由，这将导致窗口使用192.168.70.1作为源地址。 任何去往默认网关的stream量都将以公共IP为源。
如果在Windows上有一些我不知道的神奇的路线，我很乐意听到！ 但是，命令：
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
将导致添加路由如下（它在同一个接口上select公共IP作为源/链路上的网关）。
10.16.0.0 255.254.0.0 On-link 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 266
第二个虚拟适配器上的专用地址
我尝试添加虚拟networking适配器到服务器 – 首先与Microsoft环回适配器设备。 Loopback设备在networking连接列表中显示为“媒体断开”。 看到虚拟网卡没有连通性，Windows就回到了通过默认路由发送stream量（使用公共源地址）。
然后我尝试了一个不同的虚拟设备驱动程序 – OpenVPN附带的TAP虚拟适配器驱动程序。 该驱动程序允许您强制进入“始终连接”状态。 但是，在第一次ping之后，Windows再次发现该适配器上没有连接，并通过主（公共）接口上的默认网关返回stream量。
所以，这就是…任何想法？
当你尝试这样做的时候，你有点反对源IP地址select的自然倾向。 那么为什么不只是改变你的devise一点点，因为它stream动更自然？
问题是源地址的select是在决定将stream量推向隧道之前完成的。 这意味着它将select使用“公共”IP地址作为通过隧道发起的任何stream量的源IP。
在某些操作系统上，您可以使用路由来做有趣的事情，在主机发起的stream量的路由上指定源地址。 我在Windows上找不到像这样的东西。
然而，考虑到你的networkingdevise，我认为解决这个问题最简单的方法就是停止与服务器端的RFC1918地址对抗，然后在你的公共IP地址203.10.10.10和私有IP之间build立一个SA隧道地址10.16.0.0/15。
然后，客户端会将服务器的地址定为203.10.10.10，而不是192.168.70.1，而其他所有的东西都希望只是魔法般落到位。 这样，源IPselect将已经select适当的地址，将工作。
您可以在过渡期间保留旧的安全策略，以便您的客户端可以使用旧的RFC1918地址或新的公共地址对服务器进行寻址，而DNScaching过期（假设您正在使用DNS – 如果没有，这是一个好主意）。 经过一个过渡期后，地址192.168.70.1不再有function。
另一种select是在从服务器发起连接时明确select源IP地址 – 如果是自己编写的自定义软件，这可能是可能的，但这有点儿毛病。
最后，这个回送适配器的想法是有希望的，但它显示为“媒体断开”虽然很奇怪。 这听起来像回环适配器本身的问题，而不是这个想法。