开放互联网上的RFC 1918地址？

在尝试诊断我的Cisco ASA 5520防火墙的故障转移问题时，我运行了到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内部进行的路由之类的情况非常普遍。

实际上，只有网络上的边界网关才需要公用可路由的IP地址才能进行路由工作。如果路由器的接口未连接到任何其他AS（或更简单地说，是任何其他服务提供商），则无需在Internet上发布路由，只有属于同一实体的设备才需要直接连接到该AS。接口。

数据包在traceroute中以这种方式返回给您是对RFC1918的轻微违反，但实际上并不需要为这些设备使用NAT，因为它们本身不会连接到Internet上的任意设备。他们只是通过交通。

流量采取通过它的（可能是circuit回的）路由通过几个组织，这仅仅是外部网关路由协议运行的结果。微软拥有一定的骨干力量并且有人对此表示同情，这似乎是完全合理的。您无需成为批发ISP即可路由流量。

流量经过具有私有IP的多个路由器系列，再经过介于其间具有公共IP的路由器进行传输，并不奇怪-它只是表明（在这种情况下）沿路径的两个不同的网络已将流量路由到各自的路由器他们已选择以此方式编号。

不仅是RFC 1918，还有RFC 6598，即100.64.0.0/10CGN空间。这两个都是专用网络，但是后者最近被标准化并且鲜为人知。

从traceroute的角度来看，这并不罕见。您实际上并没有在直接与10space和100space主机通信，而是将具有递增的TTL的数据包发送到下一跳路由器。为避免答案过长，此Wikipedia链接总结了该过程。

什么是不寻常的是，这个数据包穿过公共IP地址空间，然后通过专用的IP地址空间隧道到达再次达成“公共”网。157.56.176.94由微软拥有，数据包在到达专用网络之前先经过MS拥有的网络...因此，这正是Microsoft选择在专用空间两端处理其网络空间的方式。他们宣传路线；其他路由器只是按照他们的要求去做。

通常，不，网络运营商通常不会从网络外部向公共IP空间的路由中暴露其私有网络。这就是为什么这如此不寻常。

（这可能是其边界某处的一条丢失的路由，导致数据包经过最终到达其目的地的非最佳路径，但我不是网络专家，所以有人可能会更好地对其进行刺杀）