Повний тунель убив ваш SSH-сеанс: закріпіть зворотний маршрут

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

Що насправді встановлює redirect-gateway

У формі def1 параметр redirect-gateway додає 0.0.0.0/1 і 128.0.0.0/1 замість перезапису маршруту за замовчуванням. Ці дві половини покривають увесь адресний простір, і обидві залишаються довшими префіксами, ніж 0.0.0.0/0, тому будь-яке призначення без конкретнішого збігу тепер іде в тунель. Саме цей механізм варто запам'ятати, бо кожне виправлення нижче працює через встановлення конкретнішого збігу.

Ваша адміністративна адреса — одна з таких цілей.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

Знайдіть свою вихідну адресу та шлях до тунелю

На сервері виведіть встановлене SSH-з'єднання та запишіть адресу партнера, з якої воно прийшло. Саме цю адресу має покривати ваш зворотний маршрут, і це не завжди те, що ви думаєте: проміжний хост, NAT-шлюз або транслятор оператора може підставити інше джерело.

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

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

Закріпіть маршрут до хоста, що переважує напівмаршрути

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Перевіряйте пошуком, а не переглядом таблиці: у відповіді мають бути eth0 і шлюз, ніколи tun0.

OpenVPN уже додає маршрут до хоста за власною адресою VPN-сервера з тієї ж причини, тож схема знайома, а адміністративна адреса — просто ще один виняток. Не вдавайтеся до route-nopull, щоб це виправити, бо він відкидає просунуті маршрути, потрібні тунелю, включно з віддаленою мережею та параметрами DNS.

Зробіть так, щоб це пережило повторне підключення

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

Підійде і скрипт route-up, і хук pre-up мережевого менеджера, а надійна перевірка — перепідключення з наступним тим самим пошуком.

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

Коли закріпленого маршруту все ще не досить

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

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

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