openvpn3 session-start ignorerer innloggingsfilen din

Koble til med 2.x-klienten, og profilen virker; gi samme fil til 3.x-klienten, og den stopper ved en passordforespørsel. Gi --auth-user-pass creds.txt til openvpn3 session-start, og resultatet er det samme, fordi den nyere klienten ikke har noe trinn som leser filen. Avvisningen er bevisst: innloggingsdata tilhører en økt, og en økt opprettes av en tjeneste, ikke av prosessen i terminalen din. Velg mellom den interaktive forespørselen og autoload-hjelperen, og vite hva hver av dem lagrer.

Hvorfor den lagrede filen ikke har noe sted å gå

I det nyere designet er konfigurasjonsstyring og øktstyring separate tjenester som snakker over systembussen. Det er denne separasjonen som lar en vanlig bruker starte en økt uten at en privilegert daemon leser en beskyttet passordfil på vegne av dem. Filbaserte innloggingsdata har ingen plass i den modellen, fordi det ikke finnes noen oppstart på daemonsiden som ville lese dem. Avvisningen er en konsekvens av arkitekturen, ikke en manglende funksjon.

Det gamle mønsteret er verdt å navngi, slik at det er lettere å avlære: en profil refererer til en innloggingsfil, og daemonen leser den når tunnelen starter. I den nye modellen tilhører innloggingsdata en økt og leveres når den økten begynner. openvpn3 session-start --config work.ovpn spør etter dem, og --auth-user-pass creds.txt avvises fordi ingenting på den veien ville åpne filen. Hver 2.x-oppskrift du finner forutsetter et trinn som ikke lenger finnes.

Konfigurasjon og nettstedets lokale innstillinger er også atskilt, noe som forklarer en andre overraskelse. En profil kan se komplett ut mens tilkoblingen den produserer mangler ruting- og resolverkonfigurasjon. De delene brukes som lokale innstillinger, atskilt fra den importerte filen.

Forespørselsveien og økten den etterlater

Å oppgi passordet når økten starter er den tiltenkte arbeidsflyten. Klienten spør én gang, gir innloggingsdataene til øktbackend-en og fortsetter:

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

Ingenting skrives til disk via den veien. Økten fortsetter også å kjøre etter at terminalen lukkes, noe som overrasker folk som forventer at prosessen skal dø med skallet. Det er poenget med å flytte økthåndteringen inn i en tjeneste. Økten lever lenger enn terminalen som ba om den, og den må stoppes eksplisitt.

For en arbeidsstasjon med et menneske foran er dette også det tryggeste alternativet, fordi det ikke finnes noen lagret hemmelighet å beskytte eller glemme. Det er bare uegnet der ingen er til stede for å skrive.

Automatisering uten en person ved tastaturet

Der en maskin må koble til uten en person, leverer prosjektet openvpn3-autoload. Den leser en katalog med profiler og en samsvarende beskrivelse per profil, og beskrivelsen gir innloggingsdataene i klartekst. Hjelperen er en separat binærfil, vanligvis på /usr/sbin/openvpn3-autoload, ikke et flagg på session-start. Å sette den opp betyr å opprette katalogen, kopiere profilen under navnet beskrivelsen forventer, og skrive beskrivelsen.

En oppsett per bruker ser slik ut, kjørt som kontoen som skal eie økten. Katalogmodusen holder andre lokale brukere ute:

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

Beskrivelsen navngir innloggingsdataene og ber om automatisk start. Hold passordverdien utenfor versjonskontroll:

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

Kall deretter hjelperen én gang og bekreft at økten dukker opp. Den andre kommandoen er sjekken, ikke et nytt oppsettstrinn:

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

Ved oppstart bruker en pakket enhet kalt openvpn3-autoload.service systemomfattende katalogen /etc/openvpn3/autoload, ikke den per bruker. Den plasseringen trenger root-eierskap og en strammere modus, og beskrivelsen holder fortsatt passordet i klartekst. Avveiningen er eksplisitt: passordet ligger nå på disk, så behandle den katalogen som en hemmelighet, utelukk den fra sikkerhetskopier utenfor verten, og velg den interaktive veien hver gang en person er til stede.

Bussfeil som ser ut som passordfeil

Noen feil som tilskrives innloggingsdata er slett ikke av den typen. En tilgangsfeil som navngir tjenestens aktiveringsvei betyr en av to ting: backend-en kjører ikke, eller den som kaller mangler tillatelse til å aktivere den. Ingen profilendring vil endre noen av dem. Sjekk tjenestetilstanden og den medfølgende buss-policyen før du rører konfigurasjonen.

Kommandoene nedenfor skiller de to. Den første rapporterer om backend-en kjører; den andre viser nylige bussfeil:

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

Den andre vanlige feillesningen er en økt som dukker opp og så forsvinner med en gang. Det mønsteret betyr vanligvis at de lokale innstillingene aldri ble brukt, så tunnelen kom opp uten rutene og resolverendringene som gjør den nyttig. Les sekvensen i stedet for den siste linjen: om økten ble opprettet, om den nådde en tilkoblet tilstand, og om den overlevde er tre separate fakta.

Når den eldre klienten fortsatt er i bruk

2.x-klienten godtar fortsatt en innloggingsfil, og en nøkkelring kan svare på forespørselen uten at hemmeligheten noen gang når disken. En wrapper løser opp oppføringen, så filen navngir oppslaget i stedet for passordet. Dette oppsettet avhenger av en ulåst nøkkelring, som en container uten innloggingsøkt eller en enhet som starter før noen logger på ikke kan tilby. Oppslagsverktøyet rapporterer da en samling det ikke kan skrive til, så feilen ser ut som en innloggingsfeil når den er en nøkkelringfeil.

Før du bygger noe av dette, sjekk om en keepalive-innstilling i profilen fjerner behovet for å starte på nytt helt. En økt som blir oppe når aldri forespørselen du prøver å automatisere.