我们在我们的网站正在运行的捷克共和国租一台服务器。
当我从美国，印度，俄罗斯或乌克兰追踪时，一切正常，跟踪日志显示查询到达托pipe公司的路由器。 所以这个网站非常适合所有这些国家。
但是，当从芬兰查询到达捷克共和国节点（xe100-5.RT.STL.PRG.CZ.retn.net [87.245.233.182]）并停止显示超时时。 我想这个节点与托pipe公司无关。 因此，芬兰的家伙们无法凝视我们华丽的网站:)
有两件事让我感到困惑：
首先，从印度跟踪通过捷克的同一个节点，IP地址匹配。 然而，追踪更进一步，并达到托pipe公司的路由器，这是不是从芬兰的情况。 这怎么可能发生？
其次，芬兰的用户在企业networking内进行跟踪。 但是，其中一名员工在家里试了一下，网站就可以访问，所以我认为跟踪也很好。
最糟糕的是，双方的帮助台都向我指出，这个问题超出了他们的责任范围。
更新：
我有从RETN谁控制RT.STL.PRG.CZ路由器的答复
从我们的镜子（ http://lg.retn.net/ ）可以看出，在捷克共和国RT.STL.PRG.CZ朝向您的IP地址之后的下一跳将是GW1-HostTelecom.retn.net（87.245 .246.98） – AS51248边界。
从第二条轨迹可以看出，他们并没有使用我们来达到芬兰的IP地址。
我build议寻找AS1759的问题的来源。
*第二次跟踪意味着从CR中的服务器追溯到芬兰客户端的IP地址
现在想知道他们是如何得出结论：成功转移stream量的AS可以为这个问题负责，而他们的路由器阻塞一切都不是责难。
第二个问题是我可以如何联系任何有关AS1759的负责人，请指点一下将ASN翻译成电子邮件的常用方法。
最后，为什么RETN把它看作是一个回溯到不同路线的问题？ 这真的是路由问题的症状吗？
可能的原因：BGP传播问题
由于configuration错误，过滤错误或财务状况匹配 ，特定的自治系统可能无法从另一个自治系统访问。 我只在我的住宅链接上遇到过这种情况，但是我确信我的ISP有点糊涂，当我把这个升级得足够让别人明白的时候。
看看一些看起来像玻璃的服务器，看看你是否能够发现有关系统如何传播地址的问题。
虽然这很奇怪，但您应该记住，您对traceroute或pingfunction并不一定意味着您将无法访问远程服务器上的某些端口或协议。 一个更准确的工具来testing某些端口实际上是否被阻塞（更具体地说，在哪一跳），尝试使用traceproto 。 它通常不是默认安装的，但它是一个通用的工具，可以通过您的发行版的包pipe理系统轻松安装。
为了更快速地testing端口和/或服务的可用性，而不必关心哪一跳丢包，你可以使用nmap 。
我build议您向公司networking的ISP提供跟踪输出，除了向他们展示来自另一个能够通过相同跳跃访问目的地的源的跟踪输出外。 他们应该能够给你提供一个理由，如果没有的话，你应该要求他们进一步调查，以确保他们的知识产权范围在任何地方都不被阻挡。