OpenVPN på Windows: starta tunneln automatiskt och behåll rutterna
En Windows-tjänst kan resa tunneln innan någon loggar in, och en skickad rutt håller kvar webbplatsens prefix bara så länge anslutningen är uppe.
Här trasslar två krav ihop sig: tunneln ska resa sig innan någon loggar in, och trafik till en andra webbplats ska följa den. Det är två separata problem med två separata mekanismer. Tjänstens start avgör det första, och rutten livslängd det andra. Att lösa det ena lämnar det andra exakt där det var.
Första steget: lägg profilen där tjänsten letar
Windows-tjänsten läser profiler från en fast mapp, och GUI:t läser från samma ställe, så en profil som fungerar när du importerar den kan ändå vara osynlig vid start. Lägg .ovpn-filerna i installationens config-mapp, som vanligtvis ligger under Program Files. En profil som lämnas i en användares Downloads-mapp ingår inte alls i tjänstens område.
Äldre vägledning pekar på en config-auto-mapp, som vissa builds från 2.5-eran respekterade och senare utgåvor inte. Därför kan en uppgradering göra en fungerande autostart tyst, utan att något om inloggningsuppgifter står i loggen. Bekräfta vilken mapp den installerade versionen faktiskt läser innan du flyttar filer.
Med flera profiler på en maskin ger du var och en en namngiven adapter via dev-node. Annars konkurrerar de om samma gränssnitt och den andra misslyckas på ett sätt som ser ut som ett problem med inloggningsuppgifter.
Andra steget: starta tjänsten i stället för statusikonen
Att sätta tjänsten OpenVPN till Automatic gör att den startar vid uppstart utan inloggning. Det är mekanismen, och statusikonen är inte en del av den. När tjänsten äger anslutningen kan GUI:t visa varken ikon eller status, vilket är förväntat och inte ett fel.
Konsekvensen är att frånkoppling innebär att stoppa tjänsten, inte att klicka på Disconnect. Säg det till den som driftar maskinen, annars handlar det första supportärendet om en saknad ikon.
Kontrollera att tjänstekontot kan läsa profilen och nyckelmaterialet. Ett behörighetsproblem vid start ser i loggen exakt ut som en misslyckad autentisering.
Tredje steget: bind rutten till tunneln
En beständig post är fel verktyg här. Att lägga till en rutt med -P gör att den överlever omstarter och, värre, att den överlever att tunneln stängs. Med VPN:et nere pekar prefixet fortfarande på en gateway som inte finns, så värden når inte det målet förrän någon tar bort posten.
Tre alternativ beter sig korrekt. Skicka rutten från servern, som lägger till den vid anslutning och tar bort den vid frånkoppling. Lägg till den i ett route-up-skript som läser route_vpn_gateway, så att nästa hopp kommer från den förhandlade tunneln. Eller använd Add-VpnConnectionRoute med en inbyggd Windows VPN-profil, som binder prefixet till den anslutningen.
När servern erbjuder mer än webbplatsen behöver avvisar route-nopull de skickade rutterna och lämnar tabellen helt lokal. Det passar en delad profil vars användare inte ska få en företagsstandardrutt.
Fjärde steget: överlev en kall start
Att starta tjänsten innan nätverksstacken finns ger ett misslyckat försök och ingen upprepning. Att sätta den till Automatic (Delayed Start), eller att lägga till ett beroende till nätverkstjänsten, tar bort det racet. Upprepa sedan starttestet och kontrollera att ett andra försök inte längre behövs.
Rutt- och adapterändringar kräver administratörsrättigheter. En autostartgenväg per användare har dem inte, så ett skript som fungerar från ett förhöjt skal kan tyst göra ingenting vid inloggning. Schemalägg det som en uppgift med de högsta rättigheterna, eller låt tjänsten äga ändringen. Testa det sedan som den användare som faktiskt loggar in.
Testa den sekvens du faktiskt driftsätter, inte den du kan utlösa för hand. En kall start är det enda test som prövar ordningen.
Femte steget: verifiera utan GUI:t
Efter en omstart och en inloggning kontrollerar du tre saker utan att öppna GUI:t. Adaptern ska hålla en adress,ruttabellen ska visa webbplatsens prefix med tunnelns gateway som nästa hopp, och en ping till en adress på andra sidan ska svara. Varje kontroll motsvarar en annan mekanism från stegen ovan.
När adaptern aldrig dyker upp är drivrutinen den misstänkta, inte profilen. De två felen ser inte alls lika ut i loggen, och bara ett av dem reagerar på ominstallation av programvara.