OpenVPN-påloggingsfil eller styresokkel: hva som bør skriptes

Et skript som starter OpenVPN og aldri kobler til, er vanligvis ikke et nettverksproblem: klienten sitter ved en ledetekst uten en terminal å tegne den på. OpenVPN har nøyaktig to støttede måter å svare på den ledeteksten uten et menneske, en påloggingsfil bak auth-user-pass og styresokkelen, og de er ikke utskiftbare. Filen koster én direktiv og svarer på én ledetekst; sokkelen svarer på hver ledetekst og gir alt som kan åpne en loopback-port en uautentisert kontrollkanal. Hvilken som hører til utrullingen din avhenger av hvilken ledetekst som faktisk blokkerer, og hvilken hemmelighet du har råd til å la ligge i ro.

Navngi ledeteksten før du velger mekanisme

Fire ledetekster ser identiske ut på en terminal. Kontoparet kommer fra serverens PAM- eller auth-user-pass-verify-oppsett og besvares av auth-user-pass. En passfrase for en privat nøkkel hører til nøkkelfilen og leses via --askpass eller skrives inn for hånd. Et PKCS#12-bundle spør om sitt eget passord. Proxy-autentisering bruker auth-filen som --http-proxy tar, ikke kontoopplysningene.

Når OpenVPN kjører som barn av systemd, PHP eller Node, finnes det ingen terminal, så enhver av disse blokkerer stille. Prosessen sitter der, loggen stopper etter chiffer-linjen, og enheten går til slutt i timeout; den stillheten er grunnen til at folk legger til en gjentakelsesløkke eller et sleep i stedet for å se hvilken ledetekst som venter. Bare styresokkelen kan svare på alle fire. Påloggingsfilen svarer på den første og ingenting annet.

auth-user-pass: én fil, én ledetekst

Filen inneholder brukernavnet på første linje og passordet på andre, og ingenting annet: ingen anførselstegn, ingen nøkkelnavn, ingen kommentar. Sett modus 600 og gjør eieren til kontoen som kjører openvpn, som for en tjeneste ofte er en dedikert bruker og ikke din egen innlogging. En fil eid av root under /root er forskjellen mellom en kommando som virker i skallet ditt og en enhet som feiler ved oppstart.

To detaljer gjør en korrekt fil til en ledetekst. En editor som lagrer CRLF, etterlater en vognretur limt til passordet, så serveren avviser et passord som ser riktig ut i filen; sjekk med cat -A eller od -c i stedet for med øyet. Og en auth-user-pass uten argument inne i profilen betyr «spør brukeren» etter design, noe en andre direktiv på kommandolinjen kanskje ikke overstyrer, fordi profilen parses der den ligger.

Rekkefølgen på valgene er den tredje fellen, og den er versjonsavhengig. Noen OpenVPN 2.4-bygg ignorerer --auth-user-pass når det står før --config, så de samme to valgene i motsatt rekkefølge kobler til. Sett direktivet i profilen, eller etter --config på kommandolinjen, og grep profilen for hver forekomst før du endrer noe annet.

auth-nocache hører til denne mekanismen, men leverer ingenting. Det begrenser hvor lenge klienten holder påloggingsdataene i minnet, noe som hjelper etter en krasj og slett ikke når filen mangler. En gjenoppkobling etter en sesjonstimeout på serversiden leser filen på nytt, så påloggingsdata som virket ved oppstart, kan fortsatt utløpe midt på dagen.

Styresokkelen: hver ledetekst, mer overflate

Start klienten med en lytter og si eksplisitt at ledetekster vil bli rapportert på den, med direktivene som er dokumentert i OpenVPN 2.6-håndboken:

management 127.0.0.1 3030
management-query-passwords

Fra bash holder du forbindelsen på en ledig fildeskriptor og svarer etter ledetekstnavn i stedet for posisjon, fordi en gjenoppkobling kan spørre i en annen rekkefølge:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

Grensen er transporten. Styringsprotokollen er klartekst over TCP på loopback, så lytteren må ikke publiseres på en LAN- eller tunneladresse for at en ekstern kontroller skal nå den; en ekstern kontroller betyr en SSH-videresending, ikke en bredere binding. Fellesskapsdæmonen godtar også bare én styringsklient om gangen, så en GUI eller monitor kan ikke dele sokkelen med skriptet ditt. Den andre forbindelsen avvises, ikke satt i kø, og feilen ser ut som et skript som har blitt døvt.

Den sokkelen er også en kontrollkanal. Uten et styringspassord kan alt som kan koble til 127.0.0.1:3030 lese status, drepe tunnelen eller svare på en ledetekst selv. Styringspassordet og påloggingsfilen er hemmeligheter i samme klasse, og begge fortjener samme omhu.

Hvilken passer til utrullingen

Velg påloggingsfilen når den eneste ledeteksten er kontoparet, klienten kjører som tjeneste med en stabil eier, og du kan holde en 600-fil utenfor sikkerhetskopier du ikke kontrollerer. Velg styresokkelen når en nøkkelpassfrase eller et PKCS#12-passord er i spill, når innpakningen allerede overvåker prosessen, eller når du må følge med på status og ledetekster mens du feilsøker en gjenoppkobling.

To vilkår flytter avgjørelsen. Hvis innpakningen er /bin/sh, en systemd-enhet som kaller binæren direkte, eller en minimal container, er bash-only sokkel-lim ikke tilgjengelig, og filen er det billigere svaret. Hvis hemmeligheten roterer ofte, er ingen av filene et godt hjem for den: spør en nøkkelring fra en liten innpakning og la enheten kalle innpakningen, noe som holder rotasjonen på ett sted og passordet ute av skallhistorikken.

Prosessubstitusjon står mellom de to og tilhører ingen av dem. Den ene linjen nedenfor virker fordi bash utvider den før openvpn starter, ikke fordi klienten forstår syntaksen:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

Den brekker under /bin/sh, i en enhet som omgår skallet, og i bilder uten bash eller /dev/fd. Behold den for interaktiv testing, aldri som kontrakten en tjeneste avhenger av.

Beskytt hemmeligheten, og verifiser deretter fra loggen

Begge mekanismene etterlater en hemmelighet som OpenVPN-prosessen kan lese. Legg aldri passordet på kommandolinjen eller i enhetsfilen, der ps og systemctl viser det til hver lokal bruker; gi stien til filen, ikke verdien i den. Der sertifikater kan erstatte kontoparet, fjerner det ledetekstkategorien i stedet for å skjule den.

En korrekt kjøring viser ledetekstsekvensen fullføres og økten nå «Initialization Sequence Completed». Hvis klienten stopper ved samme ledetekst, feilet matchingen: skriv ut de nøyaktige linjene sokkelen sendte, sjekk anførselstegn og ledetekstnavnet, og rett mønsteret i stedet for å legge til et sleep. En tunnel som rapporterer suksess og ikke bærer noe, er et ruting- eller push-problem, ikke et påloggingsproblem.

Test deretter gjenoppkoblingen, ikke bare første oppstart. Dropp sesjonen på serversiden eller vent ut timeouten; klienten spør igjen, og det er der en fil som så korrekt ut ved oppstart, viser om den fortsatt kan leses av kontoen som kobler til på nytt.