OpenVPN på Windows: start tunnelen automatisk og behold rutene
En Windows-tjeneste kan reise tunnelen før noen logger på, og en skubbet rute holder nettstedets prefiks bare så lenge forbindelsen er oppe.
Her floker to krav seg sammen: tunnelen skal reise seg før noen logger på, og trafikk til et andre nettsted skal følge den. Det er to separate problemer med to separate mekanismer. Tjenestens oppstart avgjør det første, og rutens levetid avgjør det andre. Å løse det ene lar det andre stå nøyaktig der det var.
Første trinn: legg profilen der tjenesten leter
Windows-tjenesten leser profiler fra en fast mappe, og GUI-en leser fra samme sted, så en profil som virker når du importerer den, kan likevel være usynlig ved oppstart. Legg .ovpn-filene i config-mappen til installasjonen, som vanligvis ligger under Program Files. En profil som blir liggende i en brukers Downloads-mappe, er ikke i det hele tatt innenfor tjenestens område.
Eldre veiledning peker på en config-auto-mappe, som noen bygg fra 2.5-æraen respekterte og senere utgivelser ikke. Derfor kan en oppgradering gjøre en fungerende autostart stille, uten at det står noe om påloggingsinformasjon i loggen. Bekreft hvilken mappe den installerte versjonen faktisk leser før du flytter filer.
Med flere profiler på én maskin, gi hver en navngitt adapter via dev-node. Ellers konkurrerer de om samme grensesnitt, og den andre feiler på en måte som ser ut som et problem med påloggingsinformasjon.
Andre trinn: start tjenesten i stedet for statusikonet
Å sette tjenesten OpenVPN til Automatic får den til å starte ved oppstart uten pålogging. Det er mekanismen, og statusikonet er ikke en del av den. Når tjenesten eier forbindelsen, viser GUI-en kanskje verken ikon eller status, og det er forventet, ikke en feil.
Konsekvensen er at å koble fra betyr å stoppe tjenesten, ikke å klikke på Disconnect. Si det til den som drifter maskinen, ellers blir den første supporttelefonen om et manglende ikon.
Kontroller at tjenestekontoen kan lese profilen og nøkkelmaterialet. Et tilgangsproblem ved oppstart ser i loggen nøyaktig ut som en mislykket autentisering.
Tredje trinn: bind ruten til tunnelen
En vedvarende oppføring er feil verktøy her. Å legge til en rute med -P gjør at den overlever omstarter og, verre, at den overlever at tunnelen lukkes. Med VPN-en nede peker prefikset fortsatt på en gateway som ikke finnes, så verten når ikke det målet før noen sletter oppføringen.
Tre alternativer oppfører seg riktig. Skyv ruten fra serveren, som legger den til ved tilkobling og fjerner den ved frakobling. Legg den til i et route-up-skript som leser route_vpn_gateway, slik at neste hopp kommer fra den forhandlede tunnelen. Eller bruk Add-VpnConnectionRoute med en innebygd Windows VPN-profil, som binder prefikset til den forbindelsen.
Når serveren tilbyr mer enn dette nettstedet trenger, avviser route-nopull de skubbede rutene og lar tabellen være helt lokal. Det passer en delt profil der brukerne ikke skal få en bedriftsstandardrute.
Fjerde trinn: overlev en kald oppstart
Å starte tjenesten før nettverksstakken finnes gir ett mislykket forsøk og ingen gjentakelse. Å sette den til Automatic (Delayed Start), eller å legge til en avhengighet til nettverkstjenesten, fjerner det kappløpet. Gjenta så oppstartstesten og kontroller at et andre forsøk ikke lenger er nødvendig.
Rute- og adapterendringer krever administratorrettigheter. En oppstartsnarvei per bruker har dem ikke, så et skript som virker fra en forhøyet shell, kan stille gjøre ingenting ved pålogging. Planlegg det som en oppgave med de høyeste rettighetene, eller la tjenesten eie endringen. Test det så som brukeren som faktisk logger på.
Test sekvensen du faktisk ruller ut, ikke den du kan utløse for hånd. En kald oppstart er den eneste testen som prøver rekkefølgen.
Femte trinn: verifiser uten GUI-en
Etter en omstart og en pålogging, kontroller tre ting uten å åpne GUI-en. Adapteren skal holde en adresse,rutetabellen skal vise nettstedets prefiks med tunnelens gateway som neste hopp, og en ping til en adresse på den andre siden skal svare. Hver kontroll svarer til en annen mekanisme fra trinnene over.
Når adapteren aldri dukker opp, er driveren den mistenkte, ikke profilen. De to feilene ser slett ikke like ut i loggen, og bare én av dem reagerer på reinstallering av programvare.