Чому маршрут VPN не показує шлюз у виводі ip route
Рядок із пристроєм і без шлюзу — це прямий маршрут, а не зламаний. Прочитайте пункт призначення, dev і scope, потім підтвердьте за допомогою ip route get.
Таблиці маршрутизації часто читають як зламані щоразу, коли стовпець шлюзу залишається порожнім, хоча рядок зазвичай повний сам по собі. Поле via з'являється лише тоді, коли ядро передає пакет адресі наступного переходу; маршрут, прив'язаний до інтерфейсу, досягає своїх пунктів призначення натомість через розв'язання на канальному рівні або через партнера точка-точка. Читання стовпців зліва направо каже, у якому випадку ви перебуваєте, і це читання має відбутися до того, як хтось змінить маршрут за замовчуванням. Більшість заявок про відсутній шлюз закінчуються на цій відмінності.
Читайте рядок маршруту стовпець за стовпцем
Кожен запис починається з пункту призначення та довжини його префікса, потім додає модифікатори у фіксованому словнику: via, dev, proto, scope, src і metric. Рядок на кшталт 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 щільний, але повністю визначений. У ньому нічого не бракує, і жодна адреса маршрутизатора не мається на увазі.
Цікавою є відсутність via. Без наступного переходу ядро розв'язує пункт призначення безпосередньо на вказаному інтерфейсі, що для тунелю означає передачу кадру тунельному пристрою та надання інкапсуляції діяти далі. proto kernel фіксує, що запис було встановлено автоматично під час призначення адреси, а не введено адміністратором. scope link каже, що пункт призначення доступний на цьому каналі без проходження через маршрутизатор, а src називає адресу, якій ядро віддасть перевагу як джерелу для відповідного трафіку.
Тепер прочитайте маршрут за замовчуванням так само: default via 192.0.2.254 dev eth0 proto static metric 100. Тут via присутнє, тому що пакету справді потрібен наступний перехід, і цей перехід сам має бути доступним на eth0. Ці два рядки не є варіантами один одного; вони відповідають на різні питання про те, куди йде трафік.
Дві форми маршруту, які плутають між собою
Маршрут підмережі тунелю та маршрут за замовчуванням виглядають схоже на знімку екрана і поводяться зовсім по-різному. Використайте таблицю нижче як підказку для читання полів, а потім підтвердьте реальні числа на машині, яку налагоджуєте, замість того щоб довіряти прикладу з посібника.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Те, чого таблиця не може сказати, — це намір. Прямий маршрут до приватного діапазону через тунель — це навмисний проєкт роздільного тунелю; та сама форма на хості, який мав би надсилати все через VPN, є симптомом. Намір живе в конфігурації, що створила запис, тому подивіться на інструмент, який його встановив, перш ніж зробити висновок, що ядро щось зробило не так.
Так само відсутній шлюз не дає дозволу його вигадати. Якщо маршруту справді потрібен наступний перехід, цей перехід має бути доступним на інтерфейсі, який його несе, а для тунелю точка-точка адреса партнера — не той самий об'єкт, що локальна адреса. Ставлення до локальної адреси тунелю як до Ethernet-маршрутизатора — поширений спосіб отримати маршрут, який виглядає правильним і нічого не пересилає.
Запитайте ядро, який рядок воно справді використає
Читання таблиці — не те саме, що виконання пошуку, бо перед відповіддю ядро звертається до правил політики, кількох таблиць і кешованих записів. Дієслово, яке виконує справжній пошук, — ip route get, і воно друкує маршрут, який вибрав би пакет із такими властивостями.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Підставте пункт призначення, який справді важливий, потім додайте from або iif, коли трафік вибраний за джерелом чи пересилається, бо звичайний локальний пошук може вибрати інший шлях, ніж клієнт, що пересилається. Відповідь називає інтерфейс, вибрану адресу джерела та будь-який наступний перехід, а це та сама інформація, з якою пакет було б маршрутизовано в той момент.
Якщо відповідь вас дивує, надрукуйте правила до будь-яких змін: ip -4 rule show перелічує їх у порядку пріоритету, а клієнт VPN, який встановлює власну таблицю або правило для позначених пакетів, взагалі не з'явиться в головній таблиці. Перелік усіх таблиць закриває цю прогалину.
ip -4 route show table all | grep -E 'tun|default'Перевірте нижній рівень, перш ніж замінювати маршрут за замовчуванням
Власні пакети тунелю мають дістатися віддаленої кінцевої точки, і роблять це через фізичний інтерфейс, використовуючи маршрут, що існував до підняття VPN. Заміна всього маршруту за замовчуванням без закріплення цієї кінцевої точки надсилає інкапсульовані пакети в тунель, який вони мали побудувати, і з'єднання руйнується. Спершу підтвердьте шлях до кінцевої точки пошуком лише за її адресою.
Тримайте три речі окремо, коли вносите зміну: маршрут до кінцевої точки, який має залишитися на фізичному інтерфейсі, приватні діапазони, які мають увійти в тунель, і маршрут за замовчуванням, що вирішує все інше. Розділіть їх у цьому порядку, застосовуйте по одному й повторюйте пошук після кожного кроку. Невдалий ping після цього сам по собі доводить дуже мало, оскільки дозволи, маршрутизація відповідей, DNS і сам сервіс перебувають нижче за правильний маршрут.
Запишіть чотири значення, які дала вам строка перед редагуванням: пункт призначення, наступний перехід або його відсутність, пристрій і вибране джерело. Якщо пізніша зміна зсуне будь-яке з них, ви знаєте, яке рішення насправді змінено, і можете відновити один запис замість того, щоб вгадувати всю таблицю.