OpenVPN у Windows: автозапуск тунелю та збереження маршрутів

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

Крок перший: покладіть профіль туди, де його шукає служба

Служба Windows читає профілі з фіксованого каталогу, і графічний інтерфейс читає звідти ж, тому профіль, який працює під час імпорту, може залишатися невидимим під час завантаження. Покладіть файли .ovpn у каталог config інсталяції, який зазвичай розташований у Program Files. Профіль, залишений у папці Downloads користувача, взагалі не входить до області дії служби.

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

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

Крок другий: запустіть службу, а не значок у системному треї

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

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

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

Крок третій: прив'яжіть маршрут до тунелю

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

Три альтернативи поводяться правильно. Просуньте маршрут із сервера: він додається під час підключення і видаляється під час відключення. Додайте його в скрипт route-up, який читає route_vpn_gateway, щоб наступний перехід надходив із узгодженого тунелю. Або використайте Add-VpnConnectionRoute із власним профілем VPN Windows, який прив'язує префікс до цього з'єднання.

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

Крок четвертий: переживіть холодне завантаження

Запуск служби до появи мережевого стека дає одну невдалу спробу і жодного повтору. Переведення в Automatic (Delayed Start) або додавання залежності від мережевої служби прибирає цю гонку. Потім повторіть тест завантаження і переконайтеся, що друга спроба більше не потрібна.

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

Перевіряйте ту послідовність, яку справді розгортаєте, а не ту, яку можна запустити вручну. Холодне завантаження — єдиний тест, який перевіряє порядок.

Крок п'ятий: перевірте без графічного інтерфейсу

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

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