Чому видалений маршрут VPN повертається після повторного підключення

Видалення активного маршруту нічого не змінює, якщо профіль, push або завантажувальний юніт створює його знову. Знайдіть власника, змініть його там і перевірте під час повторного підключення.

Маршрут, який ви видалили вручну, повертається після наступного повторного підключення, і таблиця виглядає точно так само, як раніше. Це не помилка маршрутизації: щось знову створює запис із конфігурації або з дії життєвого циклу з'єднання. Більшість runbook'ів зупиняються на активній таблиці, тому видалення ніби працює хвилину, а потім зривається. Визначте власника, змініть його і доведіть це під час повторного підключення.

Хто встановив маршрут

Почніть зі списку кандидатів, а не з виправлення. Профіль VPN може нести власні маршрути, сервер може надсилати їх під час підключення, профіль мережевого менеджера може їх оголошувати, завантажувальний юніт або скрипт може їх додавати, а реалізації IPsec встановлюють маршрути для узгоджуваних селекторів трафіку. Правила маршрутизації за політикою також можуть повністю перенаправляти трафік до іншої таблиці.

Час розділяє їх швидше, ніж археологія конфігурації. Запис, що з'являється в момент підняття інтерфейсу, належить клієнту; той, що приходить секундою пізніше, зазвичай прийшов із push сервера; той, що є під час завантаження, належить збереженій конфігурації. Зафіксуйте таблицю до і після підключення, відключення та перезавантаження, і шаблон назве власника. Маршрут, який повертається лише під час перезапуску служби, вказує на юніт, а не на VPN.

Прочитайте таблицю перед редагуванням

Дивіться на подання самого ядра, а не на збережений файл. Стовпець протоколу показує, що встановило кожен запис:

ip route show
ip route show table all
ip rule show

Поле протоколу, метрика й номер таблиці кажуть, чи ви дивитеся на статичний запис, запис, створений ядром, чи щось додане демоном. Список правил важливий, бо пошук може повністю покинути основну таблицю, і тоді правка там стає невидимою для застосунку, який ви налагоджуєте. Читайте рядок зліва направо: призначення, шлюз, пристрій, протокол і метрика.

Потім запитайте ядро, який маршрут воно насправді використало б. Захищена адреса — кращий зонд, ніж публічна:

ip route get 10.20.5.7

Змінюйте власника, а не симптом

Коли власник відомий, зміна належить йому. Видаліть маршрут із профілю клієнта, виправте надісланий маршрут на сервері або відредагуйте з'єднання мережевого менеджера замість додавання конкуруючого постійного маршруту, який перемагає за метрикою. Два правила, що воюють одне з одним, створюють таблицю, яку потім ніхто не зможе пояснити.

Збережіть виняток кінцевої точки. Маршрут до хоста, який надсилає власну публічну адресу сервера VPN через фізичний шлюз, — це те, що підтримує потік зовнішніх пакетів тунелю; видаліть його, і тунель спробує нести сам себе. У профілі split tunnel та сама обережність стосується локальних підмереж, які мають обходити тунель.

Повторно підключіться і перевірте обидва шляхи

Повторно підключіться, потім перевірте обидва призначення за один прохід. Захищена адреса і виключена кінцева точка відповідають на різні питання:

ip route get 10.20.5.7
ip route get 198.51.100.20

Перший має розв'язуватися через інтерфейс тунелю, а другий — через фізичний шлюз. Якщо обидва розв'язуються через тунель, винятку немає; якщо жоден, зміна профілю не набула чинності, і ви дивитеся на іншого власника, ніж думали.

Запишіть призначення маршруту, його власника і скільки він має жити. Ця нотатка — те, що не дає наступній людині повторити той самий цикл видалення й повторного підключення.

Схожі статті