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 към адрес от другата страна трябва да отговори. Всяка проверка съответства на различен механизъм от стъпките по-горе.

Когато адаптерът никога не се появи, заподозреният е драйверът, а не профилът. Тези два отказа не си приличат никак в журнала и само един от тях реагира на преинсталиране на софтуер.