Forbind med 2.x-klienten, og profilen virker; giv den samme fil til 3.x-klienten, og den stopper ved en adgangskodeprompt. Giv --auth-user-pass creds.txt til openvpn3 session-start, og resultatet er det samme, fordi den nyere klient ikke har et trin, der læser filen. Afvisningen er bevidst: legitimationsoplysninger hører til en session, og en session oprettes af en tjeneste, ikke af processen i din terminal. Vælg mellem den interaktive prompt og autoload-hjælperen, og vid, hvad hver af dem gemmer.

Hvorfor den gemte fil ikke har noget sted at blive af

I det nyere design er konfigurationsstyring og sessionsstyring separate tjenester, der taler over systembussen. Netop denne adskillelse gør det muligt for en almindelig bruger at starte en session, uden at en privilegeret dæmon læser en beskyttet adgangskodefil på brugerens vegne. Filbaserede legitimationsoplysninger har ingen plads i den model, fordi der ikke er nogen opstart på dæmonsiden, der ville læse dem. Afvisningen er en konsekvens af arkitekturen, ikke en manglende funktion.

Det gamle mønster er værd at navngive, så det er lettere at aflære: en profil henviser til en legitimationsfil, og dæmonen læser den, når tunnelen starter. I den nye model hører legitimationsoplysninger til en session og leveres, når den session begynder. openvpn3 session-start --config work.ovpn spørger efter dem, og --auth-user-pass creds.txt afvises, fordi intet på den vej ville åbne filen. Hver 2.x-opskrift, du finder, forudsætter et trin, der ikke findes længere.

Konfiguration og lokale webstedsindstillinger er også adskilt, hvilket forklarer en anden overraskelse. En profil kan se komplet ud, mens den forbindelse, den skaber, mangler routing- og resolverkonfiguration. Disse dele anvendes som lokale webstedsindstillinger, adskilt fra den importerede fil.

Prompt-vejen og den session, den efterlader

At levere adgangskoden, når sessionen starter, er det tilsigtede arbejdsforløb. Klienten spørger én gang, giver legitimationsoplysningerne til sessionsbackenden og fortsætter:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Ad den vej skrives intet til disken. Sessionen kører også videre, efter at terminalen lukkes, hvilket overrasker folk, der forventer, at processen dør med deres skal. Det er netop pointen med at flytte sessionshåndtering ind i en tjeneste. Sessionen overlever den terminal, der bad om den, og den skal stoppes eksplicit.

For en arbejdsstation med et menneske foran er dette også den sikreste mulighed, fordi der ikke er nogen gemt hemmelighed at beskytte eller glemme. Den er kun uegnet, hvor der ikke er nogen til at skrive.

Automatisering uden en person ved tastaturet

Hvor en maskine skal forbinde uden en person, leverer projektet openvpn3-autoload. Den læser en mappe med profiler og en matchende deskriptor per profil, og deskriptoren leverer legitimationsoplysningerne i klartekst. Hjælperen er en separat binærfil, normalt på /usr/sbin/openvpn3-autoload, ikke et flag på session-start. Opsætning betyder at oprette mappen, kopiere profilen under det navn, deskriptoren forventer, og skrive deskriptoren.

En opsætning per bruger ser sådan ud og køres som den konto, der skal eje sessionen. Mappens tilstand holder andre lokale brugere ude:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Deskriptoren navngiver legitimationsoplysningerne og beder om en automatisk start. Hold adgangskodeværdien ude af versionsstyring:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Kald derefter hjælperen én gang, og bekræft, at sessionen vises. Den anden kommando er kontrollen, ikke endnu et opsætningstrin:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Ved opstart bruger en pakket enhed ved navn openvpn3-autoload.service systemmappen /etc/openvpn3/autoload, ikke den per bruger. Det sted kræver root-ejerskab og en strammere tilstand, og deskriptoren holder stadig adgangskoden i klartekst. Afvejningen er eksplicit: adgangskoden ligger nu på disken, så behandl den mappe som en hemmelighed, udeluk den fra sikkerhedskopier uden for værten, og vælg den interaktive vej, når et menneske er til stede.

Busfejl, der ligner adgangskodefejl

Nogle fejl, der tilskrives legitimationsoplysninger, er slet ikke det. En tilladelsesfejl, der nævner tjenestens aktiveringssti, betyder en af to ting: backenden kører ikke, eller den kaldende mangler tilladelse til at aktivere den. Ingen profilredigering ændrer nogen af delene. Kontrollér tjenestens tilstand og den medfølgende buspolitik, før du rører konfigurationen.

Kommandoerne nedenfor skiller de to. Den første rapporterer, om backenden kører; den anden viser nylige busfejl:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

Den anden hyppige fejllæsning er en session, der dukker op og forsvinder med det samme. Det mønster betyder normalt, at de lokale webstedsindstillinger aldrig blev anvendt, så tunnelen kom op uden de routing- og resolverændringer, der gør den nyttig. Læs forløbet frem for den sidste linje: om sessionen blev oprettet, om den nåede en forbundet tilstand, og om den overlevede, er tre separate fakta.

Når den ældre klient stadig bruges

2.x-klienten accepterer stadig en legitimationsfil, og en nøglering kan svare på dens prompt, uden at hemmeligheden nogensinde når disken. En wrapper slår posten op, så filen navngiver opslaget frem for adgangskoden. Dette arrangement afhænger af en oplåst nøglering, hvilket en container uden loginsession eller en enhed, der starter før nogen logger ind, ikke kan levere. Opslagsværktøjet rapporterer så en samling, det ikke kan skrive til, så fejlen ser ud som en legitimationsfejl, når den er en nøgleringfejl.

Før du bygger noget af det, skal du kontrollere, om en keepalive-indstilling i profilen fjerner behovet for at genstarte helt. En session, der bliver oppe, når aldrig den prompt, du forsøger at automatisere.

Relaterede artikler