OpenVPN ve Windows: automatické spuštění tunelu a zachování tras

Tady se pletou dva požadavky: tunel má naskočit dřív, než se kdokoli přihlásí, a provoz pro druhou lokalitu ho má následovat. To jsou oddělené problémy s oddělenými mechanismy. Start služby rozhoduje o prvním, životnost trasy o druhém. Vyřešení jednoho nechá druhé přesně tam, kde bylo.

První krok: umístěte profil tam, kde ho služba hledá

Služba Windows čte profily z pevného adresáře a GUI čte ze stejného místa, takže profil, který funguje při importu, může být při startu neviditelný. Umístěte soubory .ovpn do adresáře config instalace, který obvykle leží pod Program Files. Profil ponechaný ve složce Downloads uživatele není pro službu vůbec v dosahu.

Starší návody ukazují na složku config-auto, kterou respektovaly některé buildy z éry 2.5 a pozdější vydání ne. Proto může upgrade proměnit fungující automatický start v ticho, aniž by v logu bylo cokoli o přihlašovacích údajích. Než přesunete jakékoli soubory, ověřte, který adresář nainstalovaný build skutečně čte.

Když je na jednom stroji několik profilů, dejte každému pojmenovaný adaptér přes dev-node. Jinak soutěží o stejné rozhraní a druhý selže způsobem, který vypadá jako problém s přihlašovacími údaji.

Druhý krok: spusťte službu, ne ikonu v oznamovací oblasti

Nastavení služby OpenVPN na Automatic způsobí, že se spustí při bootu bez přihlášení. To je ten mechanismus a ikona v oznamovací oblasti do něj nepatří. Když spojení vlastní služba, GUI nemusí zobrazit žádnou ikonu ani stav, což je očekávané, ne závada.

Důsledkem je, že odpojení znamená zastavit službu, ne kliknout na Disconnect. Řekněte to tomu, kdo stroj podporuje, jinak bude první hovor na podporu o chybějící ikoně.

Ověřte, že účet služby umí číst profil a klíčový materiál. Problém s oprávněními při bootu vypadá v logu přesně jako selhání autentizace.

Třetí krok: přivažte trasu k tunelu

Trvalý záznam je tady špatný nástroj. Přidání trasy s -P zajistí, že přežije restarty a, co je horší, že přežije zavření tunelu. Když je VPN vypnutá, prefix pořád ukazuje na bránu, která už není, takže hostitel nedosáhne cíle, dokud někdo záznam nesmaže.

Tři alternativy se chovají správně. Vnucená trasa ze serveru ji přidá při připojení a odebere při odpojení. Přidejte ji ve skriptu route-up, který čte route_vpn_gateway, takže další skok pochází z vyjednaného tunelu. Nebo použijte Add-VpnConnectionRoute s nativním profilem VPN ve Windows, který váže prefix k tomuto spojení.

Když server nabízí víc, než tahle lokalita potřebuje, route-nopull odmítne vnucené trasy a nechá tabulku zcela lokální. To sedí sdílenému profilu, jehož uživatelé nesmějí dostat firemní výchozí trasu.

Čtvrtý krok: přežijte studený start

Spuštění služby dřív, než existuje síťový stack, dá jeden neúspěšný pokus a žádné opakování. Nastavení na Automatic (Delayed Start) nebo přidání závislosti na síťové službě ten závod odstraní. Pak zopakujte test startu a ověřte, že druhý pokus už není potřeba.

Změny tras a adaptérů vyžadují práva správce. Zástupce automatického spuštění pro jednotlivého uživatele je nemá, takže skript, který funguje ze zvýšené konzole, při přihlášení může tiše nic neudělat. Naplánujte ho jako úlohu s nejvyššími oprávněními, nebo změnu nechte na službě. Pak ho otestujte jako uživatel, který se skutečně přihlásí.

Testujte posloupnost, kterou skutečně nasazujete, ne tu, kterou umíte spustit ručně. Studený start je jediný test, který procvičí pořadí.

Pátý krok: ověřte to bez GUI

Po restartu a přihlášení zkontrolujte tři věci, aniž byste otevírali GUI. Adaptér má mít adresu,tabulka tras má ukazovat prefix lokality s bránou tunelu jako dalším skokem, a ping na adresu na druhé straně má odpovědět. Každá kontrola odpovídá jinému mechanismu z kroků výše.

Když se adaptér nikdy neobjeví, podezřelý je ovladač, ne profil. Tyto dvě poruchy v logu vypadají úplně jinak a jen jedna z nich reaguje na přeinstalaci softwaru.