Як відрізнити маршрути, які просуває VPN, від статичних у Linux

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

Крок 1: назвіть механізм, який встановлює префікси

Різні протоколи забезпечують доступність по-різному, і називати все це оголошенням приховує різницю. Сервер OpenVPN просуває директиву маршруту каналом керування, і клієнт встановлює її, якщо pull-фільтр не блокує. Конфігурація WireGuard локально перелічує дозволені префікси, які клієнт використовує і для маршрутизації криптоключів, і для доданих маршрутів. Тунель IPsec узгоджує селектори трафіку з партнером, і ядро встановлює маршрути з цих селекторів.

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

Крок 2: порівняйте таблицю протягом одного підключення

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

Зніміть її командою ip route show table main > /tmp/route-down.txt, підключіться і зніміть знову. Зробіть те саме для ip -6 route, якщо сайт використовує IPv6, бо відсутній префікс там породжує збої, які виглядають не пов'язаними з маршрутизацією.

Крок 3: читайте метрику, а не лише наявність

Два записи для одного префікса можуть існувати разом, і ядро обирає меншу метрику. Статичний маршрут з метрикою 50 і далі перемагатиме просунутий маршрут зі 100, хоча видно обидва, тому «маршрут є» і «трафік іде через нього» — різні твердження.

Запитайте ядро безпосередньо командою ip route get 10.20.5.7 і прочитайте інтерфейс, який воно повідомляє. Якщо трафік виходить через фізичний адаптер, поки маршрут тунелю стоїть у таблиці, це пояснює метрика або довжина префікса, а не клієнт VPN. Повторіть пошук для хоста, про який ви знаєте, що він за тунелем, і для того, про який знаєте, що ні, і різниця покаже, чи розділення поводиться як задумано.

Крок 4: знайдіть записи, які переживають тунель

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

Перевірте постійний бік у місці, яке використовує ваш дистрибутив: модуль systemd-networkd, профіль NetworkManager або скрипт у каталозі up клієнта. Виправлення живої таблиці командою ip route del тримається лише до наступного підключення. Вважайте це видалення перевіркою гіпотези, а не ремонтом.

Там, де далекий кінець дає неправильне покриття, підніміть питання в оператора, а не фільтруйте все. Відмова від усіх просунутих налаштувань відкидає також DNS і політику розділеного тунелю, від яких залежить профіль.

Крок 5: підтвердьте зворотний шлях, перш ніж звинувачувати клієнта

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

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

Крок 6: перевіряйте ресурс, а не ping

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

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