openvpn3 session-start ignorerer innloggingsfila di

Kople til med 2.x-klienten, og profilen verkar; gje same fila til 3.x-klienten, og han stoppar ved ei passordførespurnad. Gje --auth-user-pass creds.txt til openvpn3 session-start, og resultatet er det same, fordi den nyare klienten ikkje har noko steg som les fila. Avvisinga er medvite: innloggingsdata høyrer til ei økt, og ei økt vert skapt av ein teneste, ikkje av prosessen i terminalen din. Vel mellom den interaktive førespurnaden og autoload-hjelparen, og vit kva kvar av dei lagrar.

Kvifor den lagra fila ikkje har nokon stad å gå

I det nyare designet er konfigurasjonsstyring og øktstyring separate tenester som snakkar over systembussen. Det er denne separasjonen som lèt ein vanleg brukar starte ei økt utan at ein privilegert daemon les ei verna passordfil på vegner av dei. Filbaserte innloggingsdata har ingen plass i den modellen, fordi det ikkje finst nokon oppstart på daemonsida som ville lese dei. Avvisinga er ein konsekvens av arkitekturen, ikkje ein manglande funksjon.

Det gamle mønsteret er verdt å namngje, slik at det er lettare å avlære: ein profil viser til ei innloggingsfil, og daemonen les ho når tunnelen startar. I den nye modellen høyrer innloggingsdata til ei økt og vert leverte når den økta byrjar. openvpn3 session-start --config work.ovpn spør etter dei, og --auth-user-pass creds.txt vert avvist fordi ingenting på den vegen ville opne fila. Kvar 2.x-oppskrift du finn føreset eit steg som ikkje finst lenger.

Konfigurasjon og lokale innstillingar for nettstaden er også skilde, noko som forklarer ei andre overrasking. Ein profil kan sjå komplett ut medan tilkoplinga han lagar manglar ruting- og resolverkonfigurasjon. Dei delane vert brukte som lokale innstillingar, skilde frå den importerte fila.

Førespurnadsvegen og økta han etterlèt

Å gje passordet når økta startar er den tiltenkte arbeidsflyten. Klienten spør éin gong, gjev innloggingsdataa til øktbackend-en og held fram:

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

Ingenting vert skrive til disk via den vegen. Økta held også fram med å køyre etter at terminalen er lukka, noko som overraskar folk som ventar at prosessen skal døy med skalet. Det er poenget med å flytte økthandsaminga inn i ei teneste. Økta lever lengre enn terminalen som bad om ho, og ho må stoppast eksplisitt.

For ein arbeidsstasjon med eit menneske framfor er dette også det tryggaste alternativet, fordi det ikkje finst noka lagra løyndom å verne eller gløyme. Det er berre ueigna der ingen er til stades for å skrive.

Automatisering utan ein person ved tastaturet

Der ein maskin må kople til utan ein person, leverer prosjektet openvpn3-autoload. Han les ein katalog med profilar og ein samsvarande skildring per profil, og skildringa gjev innloggingsdataa i klartekst. Hjelparen er ei separat binærfil, vanlegvis på /usr/sbin/openvpn3-autoload, ikkje eit flagg på session-start. Å setje han opp tyder å lage katalogen, kopiere profilen under namnet skildringa ventar, og skrive skildringa.

Eit oppsett per brukar ser slik ut, køyrt som kontoen som skal eige økta. Katalogmodusen held andre lokale brukarar ute:

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

Skildringa namngjev innloggingsdataa og ber om automatisk start. Hald passordverdien utanfor versjonskontroll:

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

Kall så hjelparen éin gong og stadfest at økta dukkar opp. Den andre kommandoen er sjekken, ikkje eit nytt oppsettsteg:

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

Ved oppstart brukar ei pakka eining kalla openvpn3-autoload.service den systemomfattande katalogen /etc/openvpn3/autoload, ikkje den per brukar. Den plasseringa treng root-eigarskap og ein strammare modus, og skildringa held framleis passordet i klartekst. Avveginga er eksplisitt: passordet ligg no på disk, så handsam den katalogen som ein løyndom, utelat han frå tryggleikskopiar utanfor verten, og vel den interaktive vegen kvar gong ein person er til stades.

Bussfeil som ser ut som passordfeil

Nokre feil som vert tilskrivne innloggingsdata er slett ikkje av den typen. Ein tilgangsfeil som namngjev aktiveringsvegen til tenesta tyder ein av to ting: backend-en køyrer ikkje, eller den som kallar manglar løyve til å aktivere han. Ingen profilendring vil endre nokon av dei. Sjekk tenestetilstanden og den medfølgjande buss-policyen før du rører konfigurasjonen.

Kommandoane nedanfor skil dei to. Den første rapporterer om backend-en køyrer; den andre viser nylege bussfeil:

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

Den andre vanlege feillesinga er ei økt som dukkar opp og så forsvinn med ein gong. Det mønsteret tyder vanlegvis at dei lokale innstillingane aldri vart brukte, så tunnelen kom opp utan rutene og resolverendringane som gjer han nyttig. Les sekvensen i staden for den siste linja: om økta vart oppretta, om ho nådde ein tilkopla tilstand, og om ho overlevde er tre separate fakta.

Når den eldre klienten framleis er i bruk

2.x-klienten godtar framleis ei innloggingsfil, og ein nøkkelring kan svare på førespurnaden utan at løyndomen nokon gong når disken. Ein wrapper løyser opp oppføringa, så fila namngjev oppslaget i staden for passordet. Dette oppsettet er avhengig av ein ulåst nøkkelring, som ein container utan innloggingsøkt eller ei eining som startar før nokon loggar på ikkje kan tilby. Oppslagsverktyet rapporterer då ei samling det ikkje kan skrive til, så feilen ser ut som ein innloggingsfeil når han er ein nøkkelringfeil.

Før du byggjer noko av dette, sjekk om ei keepalive-innstilling i profilen fjernar behovet for å starte på nytt heilt. Ei økt som blir oppe når aldri førespurnaden du prøver å automatisere.