Skripta en VPN-klient: välj lagret före lösenordet

Skript startar VPN-klienter på det lager som författaren valde, och det lagret är sällan det som jobbet behövde. Leverantörens kommandorad, operativsystemets uppringare och en mobil app-intent återvänder alla vid olika punkter i anslutningens liv. De hanterar också hemligheten olika, och den skillnaden avgör om lösenordet syns för varje användare på maskinen. Välj lagret innan du skriver skriptets första rad.

Lager 1: leverantörens kommandorad

De flesta skrivbordsklienter levererar en kommandorad som tar ett profilnamn och, alltför ofta, ett lösenord. Ciscos äldre klient accepterade ett connect-verb med användar- och lösenordsargument; macOS exponerar den inbyggda tjänsten via networksetup; NetworkManager svarar på nmcli. Dessa anrop återvänder när kommandot är klart, vilket inte är samma ögonblick som när tunneln blir användbar. Läs leverantörens egen dokumentation för den version du driftsätter, eftersom dessa gränssnitt ändras och en del tas bort helt.

nmcli connection up "Work VPN"
networksetup -connectpppoeservice "Work VPN"

Fördelen är att leverantören känner till sitt eget profillager, så anropet använder samma konfiguration som gränssnittet skulle göra. Nackdelen är att varje leverantör hittar på egna verb, och ett skript skrivet för en klient flyttar inte över till en annan. Betrakta det här lagret som den kortaste vägen när klienten är fast och versionen är låst.

Lager 2: operativsystemets egen tjänst

På Windows är uppringaren en del av operativsystemet, och den arbetar mot en telefonboksuppgift i stället för leverantörens profillager. Det gör den mer portabel mellan klienter och lättare att skripta från ett tjänstekonto. Det betyder också att anslutningen kan finnas på ett ställe och inte på det andra, vilket förvirrar folk som tittar i fel lista.

rasdial "Work VPN" user pass
Get-VpnConnection -Name "Work VPN" | Select-Object ConnectionStatus

Använd PowerShell-ytan när du behöver skapa eller ta bort uppgiften i stället för att ringa upp. WMI- och cmdlet-lagren exponerar samma objekt under olika namn, och borttagning är en separat operation från frånkoppling. Ett skript som bara ringer upp lämnar kvar inaktuella uppgifter efter en migrering. Kontrollera vilket lager din automatisering skriver till innan du lovar att städningen sker.

Remove-VpnConnection -Name "Old VPN" -Force
Get-VpnConnection

På macOS är motsvarigheten listan över nätverkstjänster, där en befintlig tjänst ansluts med namn i stället för att skapas på plats.

Inloggningsuppgifter läcker på varje lager, så välj kanalen

Allt du skickar på kommandoraden syns i processtabellen för varje lokal användare, och det överlever oftast också i skalhistoriken. OpenVPNs stödda alternativ är att läsa hemligheten från en fil med --askpass, och filen själv behöver behörigheter som matchar det förtroende du lägger i den. Ett namngivet rör undviker att skriva hemligheten till disk men låter varje process som kan öppna det skriva där. På Windows lagrar du hemligheten i autentiseringshanteraren, eller i en fil som bara tjänstekontot kan läsa, och aldrig som en literal i en batchfil.

openvpn --config /etc/openvpn/work.conf --askpass /etc/openvpn/work.secret --auth-nocache --daemon
ls -l /etc/openvpn/work.secret

Samma regel gäller för token och engångskoder: om automatiseringen behöver dem behöver automatiseringen en kanal som inte är ett kommandoradsargument. Rotera hemligheten när du byter mekanism, eftersom det gamla värdet har legat i en logg någonstans. Ett skript som fungerar och läcker är inte ett fungerande skript.

Vänta på tillstånd och övervaka sedan en ägare

Vart och ett av dessa anrop återvänder innan tunneln är klar, så polla det tillstånd som klienten exponerar eller sök av en destination inuti den med en timeout. Att kopiera filer eller öppna en databasanslutning direkt efter anslutningsanropet är en kapplöpning, och det misslyckas intermittent på ett sätt som ser ut som ett nätverksfel.

ip link show tun0
nmcli -t -f GENERAL.STATE connection show "Work VPN"
curl -sS --max-time 5 https://app.internal.example/health -o /dev/null

Frånkoppling har samma problem åt andra hållet: processen kan avslutas innan rutterna är borta. Använd klientens krokar där de finns, som upp- och ned-skripten i OpenVPN, eller ExecStartPost i en systemd-unit, eftersom de körs vid den punkt du faktiskt bryr dig om. Krokar körs med behörigheterna hos det som anropade dem, så en krok som startar om nätverk behöver en uttrycklig regel i stället för ett antagande. Håll exakt en ägare under anslutningens livstid.

När två övervakare både startar och stoppar den profilen, är resultatet en återanslutningsslinga som läses som ett leverantörsavbrott. Runbooken slutar när lagret är dokumenterat, hemligheten har en kanal som inte är argv, väntevillkoret är en tillståndskontroll med en timeout, och en process äger livscykeln.