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