Что делает частный IP-адрес не маршрутизируемым?

Я понимаю , что частные адреса , такие как 10.0.0.0/8, 172.16.0.0/12и 192.168.0.0/16не маршрутизируемые. Однако что именно мешает этим адресам быть маршрутизируемыми? Реализуют ли интернет-провайдеры списки ACL, которые препятствуют маршрутизации этих сетей, или это что-то более высокое?

Кроме того, это IANA создал этот дизайн?

Частные IP-адреса являются маршрутизируемыми, хотя они не являются публично маршрутизируемыми. По сути, маршрутизатор направляет частный адрес в частную / внутреннюю локальную сеть, а не в Интернет.

Чтобы расширить мой ответ: маршрутизатор может направить частный адрес на общедоступную сторону через шлюз по умолчанию. Однако пакет будет «потерян» при передаче из-за сбрасывания его другими маршрутизаторами или из-за того, что TTL пакета достигнет 0.

Например, взгляните на это (частично запутанное) traceroute -I -n 192.168.200.1:

[root@myhost ~]# traceroute -I -n 192.168.200.1
traceroute to 192.168.200.1 (192.168.200.1), 30 hops max, 60 byte packets
 1  x.x.x.x  0.851 ms  0.841 ms  0.818 ms
 2  6x.xx.xx.xx  0.791 ms  0.791 ms  0.849 ms
 3  15x.xx.xx.xx  1.350 ms  1.347 ms  1.373 ms
 4  15x.x.xx.xx  1.446 ms  1.435 ms  1.428 ms
 5  151.6.68.20  2.272 ms  2.266 ms  2.251 ms
 6  151.6.0.91  8.818 ms  8.256 ms  8.326 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
...
...
29  * * *
30  * * *

Как вы можете видеть, пакет будет направлен на интернет - общественности через шлюз по умолчанию для машины. Тем не менее, он сбрасывается во время транзита и никогда не достигает надлежащего пункта назначения.

В конце концов, частные IP / классы (по определению) перекрываются между заказчиками, так на какой из тысяч сетей 192.168.200.x / 24 следует маршрутизировать этот пакет?

Интересное примечание: интернет-провайдеры часто используют частные адреса для внутренней маршрутизации. Если, к примеру, частный 192.168.200.x / 24 классов используются для внутренней маршрутизации, первый маршрутизатор / машина с IP 192.168.200.1 будет получать , но отбросит пакет, потому что он был незапрашиваемым. ICMP - интересное исключение, так как маршрутизатор / машины обычно отвечают на незапрошенные PING. Это означает, что вы можете использовать сканирование частных адресов для сопоставления вашей частной сети провайдера.

Обычно частные IP-адреса фильтруются провайдером. Ваш маршрутизатор доступа также должен быть настроен так, чтобы они не протекали.

Частные IP-адреса нельзя использовать в Интернете, потому что их может использовать любой . Вероятно, есть много миллионов устройств, использующих 192.168.1.1 в частном порядке - какое из них является интернет-маршрутизатором, который должен отправлять пакет?

Адреса Zeroconf (169.254.0.0/16) на самом деле не маршрутизируются. Их можно использовать где угодно, но они не могут получить доступ к Интернету или какой-либо подсети, кроме своей локальной. Они не могут быть маршрутизированы, потому что они могут быть действительными только в широковещательном домене, где каждое устройство может самостоятельно выбрать неиспользуемый адрес. По определению, zeroconf не имеет экземпляра управления, подобного DHCP-серверу.

Однако что именно мешает этим адресам быть маршрутизируемыми?

Принятые стандарты, которые применяются организациями, осуществляющими связь. Они применяются в программном обеспечении, оборудовании и конфигурациях.

Реализуют ли интернет-провайдеры списки ACL, которые препятствуют маршрутизации этих сетей, или это что-то более высокое?

Они могут, но то, что действительно останавливается, - это просто неверный перевод, который не соответствует стандартам.

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

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

Снаружи у вас есть только один IP-адрес, который фактически является IP-адресом маршрутизатора. Маршрутизатор может отслеживать эти сеансы и определять, какой трафик принадлежит каждому внутреннему IP-адресу в его локальной сети, и соответствующим образом направляет этот трафик. Это сложный процесс управления, но идея становится довольно простой, если вы понимаете, что все транслируется на каждом маршрутизаторе.

Кроме того, большинство домашних маршрутизаторов имеют коммутационные порты, благодаря которым трафик доставляется через MAC-адрес, а не IP-адрес. MAC-адрес источника в пакете остается неизменным до тех пор, пока он не достигнет маршрутизатора. Маршрутизатор извлекает этот MAC-адрес источника и вставляет MAC-адрес своего собственного интерфейса WAN.

Кроме того, это IANA создал этот дизайн?

Эти стандарты изначально не были разработаны IANA. Сегодня, хотя они и играют ведущую роль в установлении стандартов, они, конечно же, не применяют их с помощью каких-либо правовых средств. Это стандарты, которые применяются на основе консенсуса. Поиск RFC 791.

Они имеют «авторитет» в той мере, в которой каждый желает их придерживаться. Полностью игнорировать эти стандарты вполне возможно, но в конечном итоге вы столкнетесь с провайдером где-то по пути, который потребует от вас придерживаться, иначе они отбросят ваш трафик.

Надеюсь, это поможет..

Как пояснение из других ответов, локальные диапазоны IP-адресов, которые вы используете локально , не маршрутизируют в Интернет, потому что они имеют свои собственные явные записи в таблице маршрутизации. Вот моя таблица маршрутов с моего рабочего стола дома, например:

$ ip route
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.104 metric 1024 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-90a372f4b373 proto kernel scope link src 172.18.0.1 linkdown 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.104 
192.168.1.1 dev enp5s0 proto dhcp scope link src 192.168.1.104 metric 1024

Обратите внимание на 172.17.0.0/16и 172.18.0.0/16. Пакеты в эти сети будут отправляться прямо на мои док-мосты, не покидая моего компьютера, потому что они имеют конкретную запись в моей таблице маршрутов. 192.168.1.0/24Запись явно говорит трафик к этой сети будет выходить на enp5s0интерфейс. Таблица маршрутов моего маршрутизатора будет иметь аналогичную запись, которая будет отправлять весь трафик для этой частной сети через интерфейс, к которому подключен мой рабочий стол.

Это только пакеты для сетей, которые явно не указаны в таблице, которые будут идти по маршруту по умолчанию. Вы можете явно пометить сеть как недоступную:

$ ip route add unreachable 10.0.0.0/8

Это меняет мою таблицу маршрутов на:

$ ip route
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.104 metric 1024 
unreachable 10.0.0.0/8 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-90a372f4b373 proto kernel scope link src 172.18.0.1 linkdown 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.104 
192.168.1.1 dev enp5s0 proto dhcp scope link src 192.168.1.104 metric 1024

Теперь мой рабочий стол даже не будет пытаться спрашивать шлюз по умолчанию об адресах в этом диапазоне. Поиск по этому адресу немедленно возвращает «Нет маршрута к хосту».

$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
connect: No route to host

Пакеты для недоступных сетей, которые явно не помечены как недоступные в таблице маршрутов, будут просто пересылаться по маршрутам по умолчанию, пока пакет не достигнет маршрутизатора, который явно знает, что сеть недоступна, или пока не истечет TTL.