☰

站点到站点 VPN tracert

tag-icon • tag-icon vpn site-to-site-vpn
站点到站点 VPN tracert

我不确定我需要多深入地研究这个问题，但目前我有一个站点到站点的 VPN 设置，并且我们在两个站点之间遇到了严重的连接问题。我进行了 tracert 并收到了一个奇怪的结果：

    Tracing route to 192.168.251.209 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.5.1.254
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4   102 ms   101 ms   103 ms  192.168.251.209

有人知道为什么请求在找到 192.168.251.209 之前超时两次吗？我们已经使用站点到站点 VPN 一年多了，从未遇到过任何问题。我以前从来没有理由运行持续的 ping 来检查数据包丢失，但今天我这样做时，数据包丢失率约为 13%。我可以 ping 其他 VPN 组和网站（google.com/shop.com），数据包丢失率为 0%。

答案1

跟踪路由中间的无响应跳跃是完全合理的 - 它只是意味着无论是什么，减少这些跳跃上的 TTL 都不想（或不能）向您发送回错误数据包。

要诊断 VPN 的问题，您需要进行数据包捕获、更多跟踪路由和 ping，并且对所涉及的架构和设备有更好的了解，然后才有希望找到问题所在。如果您想在这里获得有效的帮助，您可能需要获取所有这些信息，然后以适当简练的形式在此处提出问题。

答案2

有人知道为什么请求在找到 192.168.251.209 之前超时两次吗？

可能是以下之一：

  • 之间的系统会阻止 ICMP 或任何跟踪路由实现所使用的协议。
  • 你们之间的系统没有直接路由来回复你们的网络。

答案3

拥塞、设备故障、路由问题。

不确定数据包捕获会有什么帮助。您只会看到许多数据包没有到达另一端并且正在重新传输。如果您无法控制整个隧道的硬件，则应联系您的 SP 寻求帮助。如果可以，请开始查看该设备上的日志。

无响应的系统可能会超载到无法响应跟踪路由的程度，因为数据包很可能会被发送到 CPU 进行处理。

相关内容