假设有一个办公室使用 RRAS 桥连接到总部（2 个虚拟机使用 RRAS 在两个网络之间进行路由）。
命名：
办公室是A，A上的RRAS是a-lnk。总部是B，那里的RRAS机器是b-lnk。
VPN 运行完美 - 机器可以在站点之间 ping 通并工作。两端的域控制器正在复制，DFS 正在工作，远程桌面正在工作。总而言之...一切都很好。
例外：a-lnk 本身无法到达 B 中的任何机器。这通常不会麻烦（没有人在 a-lnk 上做任何事情），但有两个例外：* a-lnk 应该从 B 中的 KMS 获取许可证，因此无法到达 B 意味着它不会延长。* a-lnk 应该从 B 中的 WSUS 中提取更新 - 而无法到达 B 意味着 - 没有更新。
鉴于这些措施有效（而且安全性是个小问题 - A-lnk 无法从互联网访问，因为它位于 NAT 硬件后面），这个问题几个月来一直没有得到解决。我现在只想把这件事解决掉。
有人知道这是什么吗？这绝对不是“dns 不起作用”或“路由总体上很糟糕”的问题，因为 A 中的任何计算机都可以连接到 B 中的任何计算机，反之亦然 - 只有 RRAS 计算机本身似乎做了一些非常尴尬的事情。
两者的平台：2008 R2 标准。
答案1
从基础开始。
从 a 链路运行 tracert 到站点 B 中的主机，并查看 tracert 采用的路径。
a-link 的 DG 是什么？
a-link 是否有到站点 B 的静态路由？
答案2
尝试给 alink 添加一条到达 blink 的路线，反之亦然。
Alink = 10.1.1.0/24，网关 10.1.1.254
Blink = 10.1.2.0/24，网关 10.1.2.254
alink = 路由添加 10.1.2.0 掩码 255.255.255.0 10.1.1.254
blink = 路由添加 10.1.1.0 掩码 255.255.255.0 10.1.2.254
答案3
由于您说这些机器都有双 NIC，而且问题是对称的，所以我认为当连接源自 VPN 网关机器时，默认源 IP 存在问题。简单的测试用例是从两个地址执行 ping 操作（当然，要注意防火墙策略是否阻止 ping 操作）；网络 A 上的接口应该可以工作，而您的 NAT 网关（承载隧道的加密端）的接口可能是被选中的接口，因此会失败。遗憾的是，您无法在标准 Windows ping 中选择源 IPv4 地址；您需要第三方工具来测试这个假设。