OpenVPN обривається після продовження DHCP: збережіть маршрут до кінцевої точки

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

Порівняйте симптом із напівдефолтними маршрутами

З redirect-gateway def1 OpenVPN встановлює 0.0.0.0/1 і 128.0.0.0/1 замість заміни маршруту за замовчуванням. Разом ці два покривають увесь адресний простір і перемагають 0.0.0.0/0 уже самою довжиною префікса. Тому будь-який пункт призначення без точнішого збігу потрапляє в тунель.

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

Підтвердьте форму таблиці, перш ніж чіпати будь-що інше. ip route show має перелічити обидві половини плюс маршрут до вузла для адреси сервера; коли маршруту до вузла немає, у решти розслідування є очевидна відправна точка.

Чому напівдефолтні перемагають без зміни метрики

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

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

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

Зробіть три знімки, а не один

Зберіть адресу доступу, шлюз доступу, призначення кінцевої точки, вибраний маршрут і будь-які правила політики в три моменти: після налаштування каналу доступу, після підключення VPN і після події оренди або оператора. Кожен знімок — жменя команд, і вони мають сенс лише разом. Один знімок після збою фіксує стан, а не перехід. Запишіть команди в невеликий скрипт, щоб кожен знімок робився однаково.

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

Коли кінцеву точку налаштовано як ім'я, а не як адресу, розв'яжіть його і в кожному знімку. Зміна DNS на каналі доступу може зсунути кінцеву точку, взагалі не торкнувшись жодного маршруту.

Вирішіть, який компонент оновлює виняток

У системі dhcpcd хуки запускаються з каталогу хуків і з хука виходу, а режим менеджера за охопленням відрізняється від режиму на інтерфейс. Що б не робив хук, він має бути ідемпотентним, бо продовження можуть надходити пачками.

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

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

Перевіряйте життєвий цикл, а не лише перепідключення

Примусово продовжіть оренду за допомогою dhcpcd -n eth0 або звільнивши й знову взявши її, потім знову перевірте ip route get для кінцевої точки. Зробіть це двічі, бо другий прохід ловить хуки, що додають дублікати маршрутів. Потім перезавантажтеся, бо стійкість — це інша властивість, ніж коректність.

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