☰

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

tag-icon • tag-icon routing rfc
开放互联网上的 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.

答案1

路由器可以使用 RFC1918 或其他私有地址相互连接，事实上，这对于点对点链接以及 AS 内部发生的任何路由来说非常常见。

实际上，只有网络上的边界网关才需要公共可路由的 IP 地址才能使路由正常工作。如果路由器的接口不连接到任何其他 AS（或任何其他服务提供商，更简单来说），则无需在互联网上宣传该路由，只有属于同一实体的设备才需要直接连接到该接口。

数据包在 traceroute 中以这种方式返回给您，稍微违反了 RFC1918，但实际上没有必要对这些设备使用 NAT，因为它们本身并不连接到互联网上的任意东西；它们只是传递流量。

流量通过几个组织（可能绕行）的路线仅仅是外部网关路由协议运行的结果。微软拥有一些骨干网，并且一些人已经与之建立对等连接，这似乎非常合理；您不必成为批发 ISP 即可路由流量。

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

答案2

不仅仅是 RFC 1918...还有RFC 6598即100.64.0.0/10CGN 空间。两者都是私有网络，但后者标准化的时间较晚，鲜为人知。

从跟踪路由的角度来看，这并不罕见。您实际上并没有直接与那些 10space 和 100space 主机对话，而是将具有逐渐增大的 TTL 的数据包发送到下一跳路由器。为了防止答案过长，这个维基百科链接总结了这个过程。

什么是不寻常的是，这个数据包穿过公共 IP 空间，然后通过私有 IP 空间再次到达“公共”网络。157.56.176.94属于微软，数据包在到达私有网络之前穿过微软拥有的网络……所以这只是微软选择在私有空间两端使用其网络空间的方式。他们公布路由；其他路由器只是按照指示行事。

一般来说，不会。网络运营商通常不会将他们的私有网络暴露在从其网络外部到公共 IP 空间的路径上。这就是为什么这种情况如此不寻常。

（可能是他们的边界上某处缺少一条路由，导致数据包经过非最佳路径最终到达目的地，但我不是网络专家，可能有人可以更好地解决这个问题）

相关内容