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