Маршрут відхилено через біти хоста? Знайдіть потрібний префікс
Відхилений рядок маршруту зазвичай спричинений бітами хоста, а не проблемою пересилання. Визначте потрібний префікс замість розширення маски, доки рядок не буде прийнято.
Ваш рядок маршруту повертається відхиленим, а знайдена порада каже ввімкнути пересилання IP. Ці дві речі перебувають на різних етапах проблеми. Пересилання вирішує, чи може хост переміщувати пакети між інтерфейсами; воно не має думки про те, чи є введена вами адреса призначення припустимою мережею. Спершу виправте префікс, бо пересилання не врятує адресу й маску, які не узгоджуються.
На що насправді скаржиться парсер
Адреса призначення, записана як адреса плюс маска, має описувати мережу, а мережа починається з обнулених бітів хоста. Коли надана адреса все ще має значення в частині хоста, пара внутрішньо суперечлива: 172.20.130.0 виглядає охайно, бо закінчується нулем, але нуль у четвертому октеті — не єдине, що має значення. Саме третій октет тут тримає зайві біти.
Інструменти по-різному дають раду цій суперечності. Суворі парсери відхиляють рядок і називають біти хоста. М'які парсери маскують адресу й встановлюють те, чого ви не просили, що гірше, бо конфігурація тепер маршрутизує діапазон, який ви ніколи не мали на увазі. Модуль ipaddress у Python пропонує вибір безпосередньо: суворий розбір мережі спричиняє помилку, а strict=False маскує біти хоста. Ваш клієнт може бути суворим, м'яким або непослідовним між версіями, тож читайте повідомлення, а не довіряйте звичці.
Розберіть приклад вручну
Візьміть тунель, якому потрібно досягти 172.20.130.0 з маскою /20. Маска /20 позичає чотири біти в третього октету, тому цей октет рахується лише кроками по 16: 0, 16, 32 і далі до 240. Значення 130 потрапляє між 128 і 143, що означає: охопна мережа починається з 172.20.128.0, а не з 172.20.130.0 з обнуленим останнім октетом.
У явному вигляді блок іде від 172.20.128.0 до 172.20.143.255 і містить 4,096 адрес. Передача тих самих значень несуворому парсеру показує заміну, яку він зробив би від вашого імені:
$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096Вирішіть, яку адресу призначення ви насправді мали на увазі
Відхилений рядок зазвичай приховує один із трьох намірів, і вибрати можете тільки ви. Якщо тунелю потрібен увесь блок, напишіть 172.20.128.0/20, канонічну мережеву адресу. Якщо тунелю потрібен лише сегмент 130, маска була неправильна, і 172.20.130.0/24 — чесна форма. Якщо ціль — одна машина, маршрут до хоста IPv4 — це /32 і жодна арифметика масок не задіяна.
Кожен із них дозволяє різний обсяг трафіку, і це справжня причина не розширювати маску, доки скарга не припиниться. /16 приймає рядок майже всюди й надсилає трафік до адрес, які ви ніколи не хотіли маршрутизувати через тунель. Напишіть найвужчий префікс, що відповідає наміру, а потім підтвердьте його щодо наступного хопу, якого очікуєте, а не щодо тиші парсера.
Чому пересилання ніколи не було рішенням
Відхилений маршрут ніколи не досягає шляху пересилання, тому перемикання net.ipv4.ip_forward не може змінити результат. Це налаштування важливе пізніше, коли хост має пропускати пакети між інтерфейсами, і ввімкнення його до того, як таблиця стане правильною, змінює лише те, який етап відмовить наступним.
У тій самій точці часто звинувачують ще дві речі. Маршрут може бути прийнятий і все ж програти конкретнішому маршруту, а правило брандмауера може відкинути трафік після правильного пошуку. Тримайте етапи окремо: синтаксис, встановлення, вибір, фільтрування. Робота на неправильному етапі здається продуктивною, бо кожна зміна щось перезапускає.
Перевірте встановлений маршрут і шлях, який він виграє
Щойно клієнт прийме рядок, подивіться, що він установив і який маршрут ядро вибирає для представницької адреси всередині блоку. Якщо встановлений префікс відрізняється від написаного, за вас діяв нормалізатор.
Запитайте адресу-член, а також одну за межами блоку, щоб порівняння було осмисленим, а не одним заспокійливим рядком:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10Третій запит має опинитися поза тунелем, якщо префікс правильний, а якщо ні, побудований маршрут ширший, ніж ви думаєте. Запишіть, що префікс мав покривати, перш ніж торкатися наступного налаштування, бо розібраний маршрут і робочий шлях залишаються окремими спостереженнями.