我们在捷克共和国租用了一台服务器来运行我们的网站。
当我从美国、印度、俄罗斯或乌克兰跟踪它时，一切都运行正常，跟踪日志显示查询到达托管公司的路由器。因此，从所有这些国家/地区都可以很好地访问该网站。
但是，当从芬兰跟踪查询到达捷克共和国的节点（xe100-5.RT.STL.PRG.CZ.retn.net [87.245.233.182]）时，会停止显示超时。我想这个节点与托管公司无关。因此，芬兰的人无法浏览我们华丽的网站 :)
有两件事令我困惑：
首先，来自印度的追踪经过了同一个捷克节点，IP 地址确实匹配。然而追踪会进一步到达托管公司的路由器，而芬兰的情况并非如此。这怎么可能发生呢？
其次，芬兰的用户在公司网络内进行追踪。但是，当一名员工在家中尝试时，该网站可以正常访问，因此我认为追踪也正常。
最糟糕的是，双方的服务台都指责对方，称这个问题超出了他们的职责范围。
更新：
我收到了控制 RT.STL.PRG.CZ 路由器的 RETN 的回复
从我们的镜子中可以看出（http://lg.retn.net/)，RT.STL.PRG.CZ 之后朝向您的捷克 IP 地址的下一跳将是 GW1-HostTelecom.retn.net (87.245.246.98) — AS51248 边界。
从第二条跟踪信息可以看出，他们没有使用我们来访问芬兰的 IP 地址。
我建议调查 AS1759 以寻找问题的根源。
*第二次追踪是指从哥斯达黎加的服务器追溯到芬兰的客户端 IP 地址
现在想知道他们是如何得出结论的：成功传输流量的 AS 应该对这个问题负责，而阻止一切的路由器不应该受到指责。
第二个问题是我如何联系与 AS1759 相关的任何负责人，请告诉我将 ASN 转换为电子邮件的常用方法。
最后，为什么 RETN 将回溯通过不同路径视为问题？这真的是路由问题的症状吗？
答案1
答案2
虽然这很奇怪，但您应该记住，您能够访问远程服务器上的某些端口或协议traceroute并不ping一定意味着您将无法访问远程服务器上的某些端口或协议。 尝试使用 来更准确地测试某些端口是否确实被阻止（更具体地说，在哪个跳转处）traceproto。 它通常不是默认安装的，但它是一种足够常见的工具，可以通过发行版的包管理系统轻松安装。
为了更快地测试端口和/或服务可用性而不必关心哪个跳跃丢弃了数据包，您只需使用nmap。
我建议向贵公司网络的 ISP 提供跟踪输出，并向他们展示能够通过同一跳转访问目的地的其他源的跟踪输出。他们应该能够向您提供原因，如果没有，您应该要求他们进一步调查，因为确保他们的 IP 范围没有在任何地方被阻止对他们最有利。