在试图用我的思科ASA 5520防火墙来诊断故障转移问题时,我跑了一个traceroute到www.btfl.com,而且让我吃惊的是,一些跳转回来了RFC 1918地址。
只是要清楚,这个主机不在我的防火墙后面,并且没有涉及VPN。 我必须通过开放的互联网连接到那里。
这怎么/为什么这是可能的?
asa# traceroute www.btfl.com Tracing the route to 157.56.176.94 1 <redacted> 2 <redacted> 3 <redacted> 4 <redacted> 5 nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec 6 65.122.166.30 0 msec 0 msec 10 msec 7 207.46.34.23 10 msec 0 msec 10 msec 8 * * * 9 207.46.37.235 30 msec 30 msec 50 msec 10 10.22.112.221 30 msec 10.22.112.219 30 msec 10.22.112.223 30 msec 11 10.175.9.193 30 msec 30 msec 10.175.9.67 30 msec 12 100.94.68.79 40 msec 100.94.70.79 30 msec 100.94.71.73 30 msec 13 100.94.80.39 30 msec 100.94.80.205 40 msec 100.94.80.137 40 msec 14 10.215.80.2 30 msec 10.215.68.16 30 msec 10.175.244.2 30 msec 15 * * * 16 * * * 17 * * *
而且它在我家的FiOS连接上也做了同样的事情:
C:\>tracert www.btfl.com Tracing route to www.btfl.com [157.56.176.94] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms myrouter.home [192.168.1.1] 2 8 ms 7 ms 8 ms <redacted> 3 10 ms 13 ms 11 ms <redacted> 4 12 ms 10 ms 10 ms ae2-0.TPA01-BB-RTR2.verizon-gni.net [130.81.199.82] 5 16 ms 16 ms 15 ms 0.ae4.XL2.MIA19.ALTER.NET [152.63.8.117] 6 14 ms 16 ms 16 ms 0.xe-11-0-0.GW1.MIA19.ALTER.NET [152.63.85.94] 7 19 ms 16 ms 16 ms microsoft-gw.customer.alter.net [63.65.188.170] 8 27 ms 33 ms * ge-5-3-0-0.ash-64cb-1a.ntwk.msn.net [207.46.46.177] 9 * * * Request timed out. 10 44 ms 43 ms 43 ms 207.46.37.235 11 42 ms 41 ms 40 ms 10.22.112.225 12 42 ms 43 ms 43 ms 10.175.9.1 13 42 ms 41 ms 42 ms 100.94.68.79 14 40 ms 40 ms 41 ms 100.94.80.193 15 * * * Request timed out.
允许路由器使用RFC1918或其他专用地址相互连接,事实上,这对于点对点链路以及AS内发生的任何路由都是非常常见的。
只有networking上的边界网关实际上需要公用的可路由的IP地址来路由工作。 如果一个路由器的接口没有连接到任何其他的AS(或者更简单的)任何其他的服务提供者,就不需要在因特网上公布路由,只有属于同一个实体的设备才需要直接连接到接口。
在traceroute中这种方式返回给你的数据包略微违反了RFC1918,但是实际上这些设备不需要使用NAT,因为它们本身并不连接到Internet上的任意事物。 他们只是通过交通。
stream量通过几个组织进行(可能是迂回的)路由,它只是外部网关路由协议操作的结果。 微软拥有一些骨干力量,而且有些人已经注意到这一点,这似乎是完全合理的。 您不必成为批发ISP来路由stream量。
stream量已经通过多个具有私有IP的路由器系列,通过其间的公有IP进行转换并不特别奇怪 – 它只是表示(在这种情况下)沿path上的两个不同networking已经通过它们自己的路由器他们select以这种方式编号。
不只是RFC 1918 …还有RFC 6598 ,即100.64.0.0/10
CGN空间。 这两个都是私人networking,但后者是最近的标准化和较less知道。
从traceroute的angular度来看这并不罕见。 你实际上并不是直接与那些10space和100space主机通话,而是发送数据包到你的下一跳路由器。 为了保持答案过长, 这个维基百科链接总结了这个过程。
不寻常的是,这个数据包遍历公共IP空间,然后通过私有IP空间隧道到达一个“公共”networking。 157.56.176.94
归微软所有,并且数据包在打到私有networking之前通过MS拥有的networking…所以这只是微软select在私人空间两端的networking空间select。 他们宣传路线; 其他路由器只是做他们所说的。
一般来说,不,networking运营商通常不会将他们的私有networking沿着从networking外部到公共IP空间的path公开。 这就是为什么这是如此的不寻常。
(它可能是一个在他们边界的某处丢失的路由,导致数据包穿过一条非最佳的path,最终到达目的地,但我不是一个networking人,有人可能会采取更好的刺)