Я понимаю, что частные адреса, такие как 10.0.0.0/8,172.16.0.0/12 и 192.168.0.0/16 не маршрутизируемы. Однако что именно мешает маршрутизации этих адресов? Реализуют ли интернет-провайдеры списки управления доступом, которые предотвращают маршрутизацию этих сетей, или это что-то более важное?
Кроме того, 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 в частном порядке - какое из них является интернет-маршрутизатором, который должен отправлять пакет?
Зероконф адреса (169.254.0.0/16) фактически не маршрутизируемы. Их можно использовать где угодно, но они не могут получить доступ к Интернету или любой другой подсети, кроме своей локальной. Их нельзя маршрутизировать, поскольку они могут быть действительными только внутри широковещательного домена, где каждое устройство может выбрать неиспользуемый адрес самостоятельно. По определению, у zeroconf нет экземпляра управления, подобного DHCP-серверу.
Однако что именно мешает маршрутизации этих адресов?
Принятые стандарты, соблюдение которых обеспечивается общающимися организациями. Они применяются в программном обеспечении, оборудовании и конфигурациях.
Реализуют ли интернет-провайдеры списки управления доступом, которые предотвращают маршрутизацию этих сетей, или это что-то более важное?
Они могут, но то, что на самом деле прекращается, - это просто недействительный перевод, не соответствующий стандартам.
Если вы похожи на большинство домашних пользователей, вам назначен один IP-адрес в качестве общедоступного IP-адреса. Для передачи трафика от всех ваших подключенных устройств маршрутизатор выполняет преобразование этих внутренних IP-адресов с помощью NAT (преобразование сетевых адресов) или PAT (преобразование адресов портов).
По сути, ваш маршрутизатор запоминает, какие внутренние IP-адреса в вашей LAN (локальной сети) начали сеанс, выходящий за пределы вашей LAN, через маршрутизатор и из интерфейса WAN (глобальная сеть). Когда данные выходят из маршрутизатора, они содержат этот единственный 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.