What makes a private IP address not routable?
I understand that private addresses such as 10.0.0.0/8,172.16.0.0/12 and 192.168.0.0/16 are not routable. However, what exactly is stopping these addresses from being routable? Do ISPs implement ACLs that prevent these networks from routing or is it something higher up?
Also, is it IANA that created this design?
Частные 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-серверу.
В качестве пояснения из других ответов, диапазоны частных 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.
Однако, что именно мешает этим адресам быть маршрутизируемыми?
Принятые стандарты, которые соблюдаются объектами связи. Они применяются в программном обеспечении, оборудовании и конфигурациях.
Реализуют ли интернет-провайдеры списки управления доступом, которые предотвращают маршрутизацию этих сетей, или это что-то более высокое?
Могут, но на самом деле останавливается просто недопустимый перевод, который не соответствует стандартам.
Если вы похожи на большинство домашних пользователей, вам назначен один 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.
У них есть «авторитет» до такой степени, что каждый готов их придерживаться. Совершенно возможно нарушить эти стандарты, но в конечном итоге где-то на пути вы столкнетесь с провайдером, который потребует, чтобы вы действительно придерживались его правил, иначе он сбросит ваш трафик.
Я надеюсь, что это поможет ..