OpenVPN redirect-gateway: що кожен прапорець робить з маршрутами

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

Що кожен прапорець робить із маршрутом за замовчуванням

Без жодного прапорця параметр видаляє звичайний маршрут за замовчуванням і ставить на його місце тунель, тому старий шлюз зникає з таблиці, поки з'єднання активне. Додайте def1, і цей маршрут за замовчуванням залишається в списку, а роботу виконують два вужчі маршрути. Додайте bypass-dhcp, і маршрут DHCP теж виживає, що важливо в мережі, де клієнту все ще треба дістатися до локального DHCP-сервера. Список прапорців на сторінці посібника OpenVPN 2.6 досить короткий, щоб прочитати його один раз, і кожен запис змінює те, які маршрути потраплять у таблицю.

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

def1 перемагає завдяки точності, не торкаючись вашого маршруту за замовчуванням

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

Читайте таблицю, а не профіль, бо лише таблиця показує, у якому з цих випадків ви перебуваєте. Двох рядків достатньо, щоб їх розрізнити:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

Тримайте кінцеву точку тунелю доступною

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

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

ip route get 198.51.100.20

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

Трафік IPv6 далі використовує власну таблицю

Перенаправлення IPv4 залишає IPv6 у спокої, і дві родини змінюються різними прапорцями. На хості з подвійним стеком і робочим маршрутом v6 за замовчуванням трафік v4 може повністю сидіти в тунелі, тоді як кожен пункт призначення з підтримкою v6 виходить через фізичний канал. Хост, який виглядає правильно в одній таблиці, тече в іншій.

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

ip -6 route show default
ip -6 route get 2001:db8::10

Доведіть, який інтерфейс використовує застосунок

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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