Ваш старий типовий маршрут навмисно переживає OpenVPN

Ви підключаєте тунель, запускаєте ip route, а початковий типовий шлюз досі там. Наступна думка — клієнт не зміг перехопити маршрут, тож ви вручну видаляєте типовий і повністю втрачаєте зв'язок. Цей запис має залишитися. З redirect-gateway def1 OpenVPN встановлює два конкретніші маршрути, які переважають звичайний типовий замість того, щоб його замінити. Старий шлюз залишається й перестає нести трафік, який ви тестували.

Що def1 насправді робить

Прапорець додає 0.0.0.0/1 і 128.0.0.0/1, обидва вказують на тунель. 0.0.0.0/1 охоплює кожну адресу, перший октет якої від 0 до 127, а 128.0.0.0/1 — від 128 до 255, тож кожне призначення IPv4 має збіг конкретніший за старий типовий. Довжина префікса, а не метрика, вирішує, який маршрут переможе.

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

Чому /1, а не /0

Маршрутизація обирає найдовший відповідний префікс, а не найнижчу метрику, тож /1 перемагає /0, хоч би що казала метрика типового маршруту. Обидві половини існують, бо один /1 покриває лише половину простору; якщо присутній тільки 0.0.0.0/1, усе від 128.0.0.0 і вище досі йде старим типовим, що дає заплутаний симптом: частина сайтів працює, а інші ні.

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

Прочитайте справжню таблицю маршрутизації

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

Перевірте, який маршрут насправді обирає пакет

Конкретніші маршрути все ще можуть перемагати: маршрут для приватного діапазону, локальна підмережа або власна адреса сервера VPN довша за /1. Тунелю потрібен зовнішній шлях до свого сервера, і повернення цього з'єднання назад у тунель негайно його зламає. У Linux запитайте ядро замість читати таблицю на око: ip route get із потрібним призначенням друкує обраний маршрут, інтерфейс і джерело. Якщо налаштовано політичну маршрутизацію, перевірте й правила, бо правило може вибрати іншу таблицю перш ніж звернутися до основної.

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

Що def1 не покриває

Два записи IPv4 нічого не кажуть про IPv6: хост із підключенням IPv6 далі використовує власний типовий, доки щось не перенаправить цю родину окремо, тому частина трафіку ніби обходить тунель у двокладовій мережі. Інші клієнти й менеджери мереж реалізують повнотунельну маршрутизацію інакше, і їхні таблиці не збігатимуться. Поведінка def1, описана тут, належить задокументованому прапорцю OpenVPN, а не кожному VPN на машині.

Kill switch відповідає на інше питання: що робить машина, коли тунель падає. Пріоритет маршрутизації вирішує, куди йде трафік, поки тунель працює; він не вирішує, що робитиме брандмауер потім. Порядок роботи: прочитайте таблицю, переконайтеся, що обидві половини є, запустіть ip route get для проблемного призначення, перевірте правила політик, потім окремо подивіться на IPv6. Залиште старий типовий там, де він є.