OpenVPN op Windows: start de tunnel automatisch en behoud de routes

Hier raken twee eisen verstrengeld: de tunnel moet omhoogkomen voordat iemand inlogt, en verkeer naar een tweede site moet hem volgen. Dat zijn gescheiden problemen met gescheiden mechanismen. Het starten van de service bepaalt het eerste, en de levensduur van de route het tweede. Het ene oplossen laat het andere precies waar het was.

Eerste stap: zet het profiel waar de service het zoekt

De Windows-service leest profielen uit een vaste map, en de GUI leest van dezelfde plek, dus een profiel dat werkt bij het importeren kan bij het opstarten toch onzichtbaar zijn. Zet de .ovpn-bestanden in de config-map van de installatie, die meestal onder Program Files staat. Een profiel dat in de Downloads-map van een gebruiker blijft staan, valt helemaal buiten het bereik van de service.

Oudere aanwijzingen wijzen naar een config-auto-map, die sommige builds uit het 2.5-tijdperk respecteerden en latere releases niet. Daarom kan een upgrade een werkende autostart in stilte veranderen, zonder iets in het log over inloggegevens. Controleer welke map de geïnstalleerde build echt leest voordat u bestanden verplaatst.

Met meerdere profielen op één machine geeft u elk een benoemde adapter via dev-node. Anders concurreren ze om dezelfde interface en faalt de tweede op een manier die op een probleem met inloggegevens lijkt.

Tweede stap: start de service, niet het systeemvakpictogram

De service OpenVPN op Automatic zetten laat hem bij het opstarten beginnen zonder aanmelding. Dat is het mechanisme, en het systeemvakpictogram maakt er geen deel van uit. Wanneer de service de verbinding bezit, toont de GUI mogelijk geen pictogram en geen status, wat verwacht is en geen storing.

Het gevolg is dat loskoppelen betekent de service stoppen, niet op Disconnect klikken. Zeg het tegen wie de machine beheert, anders gaat de eerste supportoproep over een ontbrekend pictogram.

Controleer of het serviceaccount het profiel en het sleutelmateriaal kan lezen. Een rechtenprobleem bij het opstarten ziet er in het log precies uit als een mislukte authenticatie.

Derde stap: bind de route aan de tunnel

Een permanente vermelding is hier het verkeerde gereedschap. Een route toevoegen met -P laat hem herstarts overleven en, erger, ook het sluiten van de tunnel. Met de VPN uit wijst het prefix nog steeds naar een gateway die er niet meer is, dus de host bereikt die bestemming niet tot iemand de vermelding verwijdert.

Drie alternatieven gedragen zich correct. Push de route vanaf de server, die hem toevoegt bij verbinden en verwijdert bij loskoppelen. Voeg hem toe in een route-up-script dat route_vpn_gateway leest, zodat de volgende hop uit de onderhandelde tunnel komt. Of gebruik Add-VpnConnectionRoute met een native Windows VPN-profiel, dat het prefix aan die verbinding bindt.

Biedt de server meer dan deze site nodig heeft, dan weigert route-nopull de gepushte routes en blijft de tabel volledig lokaal. Dat past bij een gedeeld profiel waarvan de gebruikers geen bedrijfsstandaardroute mogen ontvangen.

Vierde stap: overleef een koude start

De service starten voordat de netwerkstack bestaat levert één mislukte poging en geen herhaling. Hem op Automatic (Delayed Start) zetten, of een afhankelijkheid van de netwerkservice toevoegen, haalt die race weg. Herhaal daarna de opstarttest en controleer dat een tweede poging niet meer nodig is.

Route- en adapterwijzigingen vereisen beheerdersrechten. Een opstartsnelkoppeling per gebruiker heeft die niet, dus een script dat vanuit een verhoogde shell werkt, kan bij aanmelding stil niets doen. Plan het als taak met de hoogste rechten, of laat de service de wijziging overnemen. Test het daarna als de gebruiker die echt inlogt.

Test de volgorde die u echt uitrolt, niet die u handmatig kunt activeren. Een koude start is de enige test die de volgorde oefent.

Vijfde stap: verifieer zonder de GUI

Controleer na een herstart en een aanmelding drie dingen zonder de GUI te openen. De adapter moet een adres houden,de routetabel moet het site-prefix tonen met de tunnelgateway als volgende hop, en een ping naar een adres aan de andere kant moet antwoorden. Elke controle hoort bij een ander mechanisme uit de stappen hierboven.

Als de adapter nooit verschijnt, is het stuurprogramma de verdachte en niet het profiel. Die twee storingen lijken in het log totaal niet op elkaar, en slechts één van beide reageert op herinstallatie van software.