☰

离开 DNS 后数据包被丢弃

tag-icon • tag-icon domain-name-system
离开 DNS 后数据包被丢弃

我正在尝试从我的公司访问一个域名。我在 ip:443 上执行跟踪路由，到达 DNS 后跟踪失败。我想知道错误出在哪里。

跟踪的最后四行：

    10 er1-te-3-1.sanjoseequinix.savvis.net (204.70.200.129) 15.641 毫秒 12.127 毫秒 14.280 毫秒
    11 cr1-tenge-0-3-5-0.sanfrancisco.savvis.net (204.70.200.198) 18.039 毫秒 17.210 毫秒 18.242 毫秒
    12 cr2-bundle-pos-1.losangeles.savvis.net (204.70.197.29) 23.199 毫秒 24.002 毫秒 27.607 毫秒
    13 er2-tengig-3-1.lay.savvis.net (204.70.198.10) 24.649 毫秒 24.145 毫秒 25.182 毫秒
    14 phyber.losangeles.savvis.net (208.173.55.226) 30.955 毫秒 20.603 毫秒 25.967 毫秒

答案1

当您尝试联系宿主时看到了什么症状？

您所说的“在 ip:443 上执行跟踪路由”是什么意思？端口与跟踪路由无关。您能向我们展示您正在执行的实际跟踪路由命令吗？

跟踪路由是到 DNS 服务器还是到目标主机？

我对“到达 DNS 后跟踪失败”也感到困惑，因为到主机的跟踪路由不会遍历用于解析主机的 DNS 服务器……除非 DNS 服务器也是您的网关。您能稍微澄清一下这个说法吗？

假设目标主机是 208.173.55.226，该跟踪看起来不错。Traceroute 实际上的实用性有些有限，因为当合法端口的正常 TCP/UDP 数据包被接受时，它经常会被丢弃。在某些情况下，使用 tcptraceroute 可能会有所帮助。

答案2

只是猜测 - 但请尝试不同的 DNS。18.72.0.3 是麻省理工学院的一个 DNS，它从未让我失望过。

答案3

根据该跟踪，您没有丢失任何数据包...30ms 是一个相当合理的返回时间。

不过需要澄清的是，DNS 和 traceroute（使用 ICMP）都不知道端口 443（第 4 层）。除非您使用基于 TCP 的 traceroute，否则您可能会看到 tracert 将 443 转换为 IP 地址（您是否看到有关 0.0.1.187 的消息？），然后尝试跟踪到它。检查我的 Windows 框上的行为，如果您这样做，似乎确实会发生这种情况：tracert valid.ip.add.ress 443 跟踪到 0.0.1.187 的路由，最多 30 个跳数 1 * ^C

答案4

Traceroute 是一种 ICMP 诊断，并不总是能给出与 TCP 连接相同的结果。使用tracetcp，执行基于 TCP 的跟踪路由可以在这些情况下提供更多信息。

如果这些是最后四行（即：之后没有“* * *”行），那么您的跟踪路由正在到达目的地，因此您需要开始查看服务器未响应 Web 请求的原因 - 尝试 telnet 到端口 80（http）或 443（https）以查看您是否可以打开到相应端口的连接。

telnet remote.server.com 80

如果您无法建立 TCP 连接，则使用 tracetcp 查看连接何时失败 - 可能是您这边的防火墙或远程端的防火墙/死服务/等等。一旦您确切知道数据包失败的位置，您就可以联系相关人员。如果您可以在端口 80/443 上建立 TCP 连接，则联系远程管理员，因为此后没有响应意味着他们有一个服务正在监听，但没有返回正确的响应。

相关内容