Запускаєте VPN-клієнт через SSH? Спершу закріпіть власний маршрут

Ви підключаєтеся по SSH до складального хоста, запускаєте на ньому VPN-клієнт, і сесія перестає відповідати. Нічого не впало, і ніщо не виглядає налаштованим неправильно в очевидному сенсі. Клієнт встановив маршрут за замовчуванням, тож відповіді на вашу робочу станцію тепер виходять через тунель, де адреса вашої робочої станції не маршрутизується. Цікаво те, що цей результат був передбачуваним, а виправлення — один маршрут, записаний до запуску клієнта. Припустімо сервер з однією мережевою картою, шлюз 192.0.2.254 і адміністратора, який підключається з 203.0.113.9.

Запишіть шлях до початку роботи

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

Важливе вже встановлене з’єднання, тому не перевіряйте лише новим входом. Нова сесія може ненадовго вдатися завдяки стану, якого стара вже не має.

Закріпіть адресу в конфігурації самого клієнта

Маршрут, доданий вручну, зникає після перезавантаження і конкурує з власними оновленнями таблиці клієнта, тож помістіть виняток туди, де таблицею керують. У OpenVPN ключове слово net_gateway розв’язується в шлюз, який існував до тунелю, тому route 203.0.113.9 255.255.255.255 net_gateway залишає рівно одну адресу ззовні. WireGuard потребує іншого підходу, бо wg-quick сам керує маршрутами: задайте Table = off і додайте виняток у PostUp, з відповідним PostDown, який його видаляє. Обидві форми виражають той самий намір, і обидві обмежують виняток однією адресою замість послаблення тунелю для всього.

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

Або приберіть головну таблицю з рівняння

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

Обидва — більше механіки, ніж один маршрут до хоста, і обидва варті того, коли на машині більше однієї речі має пережити тунель.

Припустіть, що закріплення може не вдатися

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

Два запобіжні заходи коштують десять хвилин. Сторож, який зупиняє клієнт, якщо підтверджувальний вхід не з’явився за кілька хвилин, перетворює блокування на затримку, а друга SSH-сесія, утримувана відкритою під час зміни, доводить, що виняток працює, поки тунель піднятий. Самі лише keepalive тут не допомагають, бо шлях зник, а не простоює; вони лише роблять смерть помітнішою.

Перевіряйте в тому порядку, який важливий

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

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