ifconfig-noexec не врятує вашу SSH-сесію: що він насправді робить
Він пригнічує власне налаштування адреси інтерфейсу в OpenVPN. Він не резервує маршрут відповіді для SSH, не вимикає всі зміни маршрутів і не надає відсутню адресу.
В одній темі форуму ifconfig-noexec його пропонують як виправлення, яке зберігає SSH-сесію живою, коли піднімається тунель. Міркування звучить правдоподібно, доки не перевіриш, чого насправді торкається ця опція. Вона заважає OpenVPN налаштовувати адресу інтерфейсу тунелю і натомість передає ці значення скриптам; про те, куди йдуть відповіді на ваше керівне з’єднання, вона не каже нічого. Віра в протилежне дає тунель без придатної адреси і SSH-сесію, яка все одно обривається.
Що ця опція насправді делегує
За замовчуванням клієнт піднімає пристрій тунелю і призначає локальну та віддалену адреси, які передав йому сервер. Коли ifconfig-noexec задано, цей крок пропускається, а узгоджені значення експортуються в середовище скриптів, щоб щось інше могло їх застосувати.
Володіння переходить. На його місці нічого не вигадується.
Отже, питання, на яке відповідає опція, — хто налаштовує інтерфейс, а питання, на яке вона не відповідає, — як пакети знаходять шлях назад до вас. Тримайте ці дві речі окремо, інакше проведете весь вечір, редагуючи маршрути, щоб компенсувати інтерфейс без адреси.
Три схожі опції з різними завданнями
Цю родину легко переплутати, бо назви різняться одним словом, а симптоми перетинаються. Прочитайте, що пригнічує кожна, перш ніж вибирати будь-яку.
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
Це альтернативи, які треба розуміти окремо, а не набір для склеювання. Пригнічення налаштування адреси не пригнічує зміни маршрутів, правила брандмауера чи просунуті опції, що несуть DNS. Делегований скрипт також вільний змінювати маршрути, і це рішення, яке ви передаєте, а не уникаєте.
Якщо клієнт постачальника обгортає рушій, використовуйте його підтримувану інтеграцію замість того, щоб кидати директиву низького рівня в профіль і сподіватися, що обгортка її поважатиме. Обгортки часто перестворюють профіль під час підключення, тож ручна правка зникає без помилки. Перевірте, де клієнт зберігає свої налаштування, перш ніж витратити на файл цілий вечір. Це стосується кожного рядка таблиці, а не лише того, за яким ви прийшли.
SSH-сесія, яку ви хотіли захистити
SSH-з’єднання має адресу джерела, адресу призначення і шлях відповіді. На сервері, який щойно встановив типове повне тунелювання, відповідь на вашу публічну адресу збігається з тунелем, і VPN-шлюз її відкидає.
Ніщо в налаштуванні адрес інтерфейсу тунелю цього не змінює.
Виправляє це конкретніший маршрут для вашої керівної адреси через шлюз до тунелю або правило політики, що спрямовує той трафік, плюс налаштування фільтра, які застосовує ваш хост. Дві проблеми іноді з’являються разом, і саме так одну приймають за ліки від іншої. Перевіряйте їх окремо: підніміть тунель без опції, подивіться на адресу інтерфейсу та шлях відповіді, а потім вирішіть, яка з двох справді зламана.
Що має взяти на себе делегований скрипт
Якщо ви справді хочете, щоб інтерфейс налаштовував інший власник, перелічіть роботу: застосуйте локальну та віддалену адресу, підніміть пристрій, відновіть або видаліть адресацію під час розбирання і зробіть те саме ще раз після повторного підключення. Значення з однієї вдалої сесії не можна зашивати в код, бо наступного разу сервер може дати іншу пару.
Змінні середовища, які експортує клієнт, — єдиний підтримуваний вхід для цієї роботи.
env | grep -E '^ifconfig_|^route_'Усередині скрипта route-up ці змінні доступні; із завдання cron або ручної оболонки — ні. Підтвердьте, який гачок життєвого циклу використовує ваша версія, і підтвердьте, що гачок працює з достатніми правами для зміни інтерфейсу, оскільки клієнт міг уже опуститися до непривілейованого користувача.
Перевіряйте весь життєвий цикл, а не одну сесію
Підніміть тунель, перевірте адресу на пристрої, потім перепідключіться і перевірте знову. Конфігурація, яка працює один раз і збоїть з другої спроби, зазвичай означає, що делегований крок виконується лише під час першого підключення.
Потім перевірте обидва критерії приймання разом: нове SSH-з’єднання через задуманий шлях керування працює, і дозволений застосунок правильно використовує тунель.
Стара SSH-сесія, яка випадково виживає, поки тунель не має адреси, — не успіх, і саме цей стан створює опція, коли роботу ніхто не бере. Спершу перевірте адресу інтерфейсу, потім шлях відповіді керування, потім застосунок. Якщо два з трьох неправильні, опція перемістила роботу, але не дала їй власника.