Geloofsbrieflêer of bestuursok by OpenVPN: wat om te skripteer

’n Skrip wat OpenVPN begin en nooit konekteer nie, is gewoonlik nie ’n netwerkprobleem nie: die kliënt sit by ’n vraag sonder ’n terminal om dit op te wys. OpenVPN het presies twee ondersteunde maniere om daardie vraag sonder ’n mens te beantwoord, ’n geloofsbrieflêer agter auth-user-pass en die bestuursok, en dié is nie onderling verwisselbaar nie. Die lêer kos een richtlijn en beantwoord een vraag; die sok beantwoord elke vraag en gee enigiets wat ’n loopback-poort kan oopmaak ’n ongeverifieerde beheerkanaal. Watter een by jou ontplooiing pas, hang daarvan af watter vraag werklik vassteek, en watter geheim jy kan bekostig om in rus te laat.

Noem die vraag voordat jy ’n meganisme kies

Vier vrae lyk op ’n terminal identies. Die rekeningpaar kom van die bediener se PAM- of auth-user-pass-verify-opset en word deur auth-user-pass beantwoord. ’n Privaatsleutel-wagfrase hoort by die sleutellêer en word deur --askpass gelees of met die hand getik. ’n PKCS#12-bundel vra ’n eie wagwoord. Proksiverifikasie gebruik die auth-lêer wat --http-proxy neem, nie die rekeninggeloofsbriewe nie.

Wanneer OpenVPN as kind van systemd, PHP of Node loop, is daar geen terminal nie, so enige van dié vrae blokkeer stil. Die proses sit daar, die log stop ná die cipher-reël, en die eenheid loop uiteindelik uit op ’n tydsverloop; dié stilte is hoekom mense ’n herprobeer-lus of ’n slaap byvoeg in plaas daarvan om te kyk watter vraag hang. Net die bestuursok kan al vier beantwoord. Die geloofsbrieflêer beantwoord die eerste een en niks anders nie.

auth-user-pass: een lêer, een vraag

Die lêer hou die gebruikersnaam op reël een en die wagwoord op reël twee, met niks anders nie: geen aanhalingstekens, geen sleutelname, geen kommentaar. Stel modus 600 en maak die eienaar die rekening wat openvpn loop, wat vir ’n diens dikwels ’n toegewyde gebruiker is eerder as jou aanmelding. ’n Lêer in besit van root onder /root is die verskil tussen ’n opdrag wat in jou dop werk en ’n eenheid wat by die opstart faal.

Twee besonderhede verander ’n korrekte lêer in ’n vraag. ’n Redigeerder wat CRLF stoor, laat ’n karretjie-terugkeer aan die wagwoord kleef, so die bediener verwerp ’n wagwoord wat in die lêer korrek lyk; kyk met cat -A of od -c eerder as met die oog. En ’n auth-user-pass sonder argument binne die profiel beteken “vra die gebruiker” volgens ontwerp, wat ’n tweede richtlijn op die opdragreël dalk nie oorheers nie, want die profiel word geparseer waar dit staan.

Opsievolgorde is die derde strik, en dit is weergawe-spesifiek. Sommige OpenVPN 2.4-bouwe ignoreer --auth-user-pass wanneer dit voor --config verskyn, so dieselfde twee opsies in die ander volgorde konekteer. Sit die richtlijn binne die profiel, of ná --config op die opdragreël, en grep die profiel vir elke voorkoms voordat jy iets anders verander.

auth-nocache hoort by dié meganisme maar voorsien niks. Dit beperk hoe lank die kliënt die geloofsbrief in geheue hou, wat ná ’n ineenstorting help en glad nie wanneer die lêer ontbreek nie. ’n Herverbinding ná ’n sessie-tydsverloop aan die bediener se kant lees die lêer weer, so ’n geloofsbrief wat by die opstart gewerk het, kan steeds midde-in die dag verval.

Die bestuursok: elke vraag, meer oppervlak

Begin die kliënt met ’n luisteraar en sê uitdruklik dat vrae daarop gerapporteer sal word, met die richtlyne gedokumenteer in die OpenVPN 2.6-handleiding:

management 127.0.0.1 3030
management-query-passwords

Hou vanuit bash die verbinding op ’n spaar lêerbeskrywer en antwoord op vraagnaam eerder as op posisie, want ’n herverbinding kan in ’n ander volgorde vra:

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

Die grens is die vervoer. Die bestuursprotokol is gewone teks oor TCP op loopback, so die luisteraar moet nie op ’n LAN- of tonneladres gepubliseer word sodat ’n afstandbeheerder dit kan bereik nie; ’n afstandbeheerder beteken ’n SSH-aanstuur, nie ’n wyer binding nie. Die gemeenskapsdaemon aanvaar ook net een bestuurskliënt op ’n slag, so ’n GUI of ’n monitor kan nie die sok met jou skrip deel nie. Die tweede verbinding word geweier, nie in die ry gesit nie, en die fout lyk soos ’n skrip wat doof geword het.

Daardie sok is ook ’n beheerkanaal. Sonder ’n bestuurswagwoord kan enigiets wat aan 127.0.0.1:3030 kan koppel, status lees, die tonnel doodmaak of self ’n vraag beantwoord. Die bestuurswagwoord en die geloofsbrieflêer is dieselfde klas geheim, en albei verdien dieselfde sorg.

Watter een pas by die ontplooiing

Kies die geloofsbrieflêer wanneer die enigste vraag die rekeningpaar is, die kliënt as ’n diens met ’n stabiele eienaar loop, en jy ’n 600-lêer uit rugsteune kan hou wat jy nie beheer nie. Kies die bestuursok wanneer ’n sleutelwagfrase of ’n PKCS#12-wagwoord in die spel is, wanneer die omhulsel die proses al toesig hou, of wanneer jy toestand en vrae wil dophou terwyl jy ’n herverbinding ontfout.

Twee voorwaardes skuif die besluit. As die omhulsel /bin/sh is, ’n systemd-eenheid wat die binary direk roep, of ’n minimale houer, dan is die bash-only sokgom nie beskikbaar nie en is die lêer die goedkoper antwoord. As die geheim dikwels roteer, is nie een van die lêers ’n goeie tuiste daarvoor nie: vra ’n sleutelring uit ’n klein omhulsel en laat die eenheid die omhulsel roep, wat rotasie op een plek hou en die wagwoord uit die dopgeskiedenis.

Prosesvervanging sit tussen die twee en hoort by nie een nie. Die eenreël hieronder werk omdat bash dit uitbrei voordat openvpn begin, nie omdat die kliënt die sintaksis verstaan nie:

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

Dit breek onder /bin/sh, in ’n eenheid wat die dop omseil, en in beelde sonder bash of /dev/fd. Hou dit vir interaktiewe toetsing, nooit as die kontrak waarvan ’n diens afhanklik is nie.

Beskerm die geheim, dan verifieer uit die log

Albei meganismes laat ’n geheim leesbaar deur die OpenVPN-proses. Moet nooit die wagwoord op die opdragreël of in die eenheidlêer sit nie, waar ps en systemctl dit aan elke plaaslike gebruiker wys; gee die pad na die lêer, nie die waarde daarin nie. Waar sertifikate die rekeningpaar kan vervang, verwyder dit die kategorie vraag eerder as om dit weg te steek.

’n Korrekte loop wys die vrae-reeks voltooi en die sessie wat “Initialization Sequence Completed” bereik. As die kliënt by dieselfde vraag stop, het die passing gefaal: druk die presiese reëls wat die sok gestuur het, kontroleer aanhaling en die vraagnaam, en maak die patroon reg eerder as om ’n slaap by te voeg. ’n Tonnel wat sukses rapporteer en niks dra nie, is ’n herleidings- of push-probleem, nie ’n geloofsbriefprobleem nie.

Toets dan die herverbinding, nie net die eerste begin nie. Laat vaar die sessie aan die bediener se kant of wag sy tydsverloop uit; die kliënt vra weer, en dit is waar ’n lêer wat by die opstart korrek gelyk het, wys of dit steeds leesbaar is vir die rekening wat weer koppel.