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 (или любым другим поставщикам услуг, проще), нет необходимости объявлять маршрут в Интернете, и только оборудование, принадлежащее тому же объекту, должно будет напрямую подключаться к интерфейс.

То, что пакеты возвращаются вам таким образом в traceroute, является небольшим нарушением RFC1918, но на самом деле нет необходимости использовать NAT для этих устройств, поскольку они сами не подключаются к произвольным вещам в Интернете; они просто проходят по трафику.

То, что трафик проходит (возможно, по кругу) через несколько организаций, что он делает, является лишь следствием работы протоколов маршрутизации внешних шлюзов. Кажется совершенно разумным, что у Microsoft есть какой-то костяк, и некоторые люди с этим позаботились; Вам не нужно быть оптовым провайдером для маршрутизации трафика.

То, что трафик проходил через несколько серий маршрутизаторов с частными IP-адресами, проходя через те из них с публичными IP-адресами между ними, не особенно странно - это просто указывает (в данном случае), что две разные сети вдоль пути маршрутизировали трафик через свои собственные маршрутизаторы. которые они выбрали для нумерации таким образом.

Не только RFC 1918 ... также RFC 6598 , то есть 100.64.0.0/10пространство CGN. Обе они являются частными сетями, но последняя сравнительно недавно стандартизирована и менее известна.

Это не необычно с точки зрения трассировки. Вы на самом деле не общаетесь с этими 10пространственными и 100пространственными хостами напрямую, вы отправляете пакеты с постепенно увеличивающимися TTL на ваш маршрутизатор следующего перехода. Чтобы избежать слишком длинного ответа, эта ссылка на Википедию суммирует процесс.

Что является необычным является то, что , что этот пакет проходит через пространство публичного IP, а затем по туннелю через частный IP пространство для достижения «общественной» сети еще раз. 157.56.176.94принадлежит Microsoft, и пакет проходит через сети, принадлежащие MS, прежде чем попасть в частную сеть ... так что это просто то, что Microsoft предпочитает делать со своим сетевым пространством на обоих концах частного пространства. Они рекламируют маршруты; другие маршрутизаторы просто делают то, что им говорят.

Как правило, нет, сетевые операторы обычно не выставляют свои частные сети на пути к общедоступному IP-пространству за пределами своей сети. Вот почему это так необычно.

(это может быть отсутствующий маршрут где-то на их границе, в результате чего пакеты пересекают неоптимальный путь, который в конечном итоге достигает своего места назначения, но я не сетевой парень, и кто-то, возможно, сможет лучше на него ответить)