OpenVPN-en egiaztagiri-fitxategia edo kudeaketa-socket-a: zein scripteatu

OpenVPN abiarazi eta inoiz konektatzen ez duen script bat normalean ez da sare-arazo bat: bezeroa gonbite baten aurrean dago, hura marrazteko terminalik gabe. OpenVPN aplikazioak zehazki bi modu onartu ditu gonbite horri gizakirik gabe erantzuteko, auth-user-pass atzean dagoen egiaztagiri-fitxategia eta kudeaketa-socket-a, eta ez dira trukagarriak. Fitxategiak direktiba bat kostatzen du eta gonbite bat erantzuten du; socket-ak gonbite guztiak erantzuten ditu eta loopback ataka ireki dezakeen edozeri kontrol-kanal autentifikatu gabea ematen dio. Bi horietatik zein dagokion zure inplementazioari dagoeneko blokeatzen ari den gonbitearen eta atsedenean uzteko moduko sekretuaren araberakoa da.

Izenda ezazu gonbita mekanismoa aukeratu aurretik

Lau gonbite berdinak dirudite terminalean. Kontu-parea zerbitzariaren PAM edo auth-user-pass-verify ezarpenetik dator eta auth-user-pass-ek erantzuten dio. Gako pribatuaren pasaesaldia gako-fitxategiarena da eta --askpass bidez irakurtzen da edo eskuz idazten da. PKCS#12 sorta batek bere pasahitza eskatzen du. Proxy autentifikazioak --http-proxy-k hartzen duen auth fitxategia erabiltzen du, ez kontuaren egiaztagiriak.

OpenVPN systemd, PHP edo Node-ren seme gisa exekutatzen denean ez dago terminalik, beraz horietako edozein isilik blokeatzen da. Prozesua han eserita geratzen da, erregistroa zifratze-lerroaren ondoren gelditzen da eta unitateak azkenean denbora-muga gainditzen du; isiltasun hori da jendeak berriro saiatzeko begizta edo sleep bat gehitzen duen arrazoia, zein gonbite dagoen zain begiratu beharrean. Kudeaketa-socket-ak bakarrik erantzun diezaioke lauei. Egiaztagiri-fitxategiak lehenengoari erantzuten dio eta besterik ez.

auth-user-pass: fitxategi bat, gonbite bat

Fitxategiak erabiltzaile-izena lehen lerroan eta pasahitza bigarrenean gordetzen ditu, eta besterik ez: komatxorik gabe, gako-izenik gabe, iruzkinik gabe. Ezarri 600 modua eta egin jabea openvpn exekutatzen duen kontua, zerbitzu baterako sarritan zure saio-hasiera izan beharrean erabiltzaile dedikatu bat baita. /root azpian root-en jabetzako fitxategia zure shell-ean funtzionatzen duen komando baten eta abiaraztean huts egiten duen unitate baten arteko aldea da.

Bi xehetasek fitxategi zuzen bat gonbite bihurtzen dute. CRLF gordetzen duen editoreak pasahitzari itsatsitako itzulera-karakterea uzten du, beraz zerbitzariak fitxategian zuzena dirudien pasahitza baztertzen du; egiaztatu cat -A edo od -c-rekin, begiarekin beharrean. Eta profilean barruan argumenturik gabeko auth-user-pass batek «galdetu erabiltzaileari» esan nahi du diseinuaren arabera, eta komando-lerroko bigarren direktiba batek agian ez du gaindituko, profila dagoen lekuan analizatzen delako.

Aukeren ordena hirugarren tranpa da, eta bertsioaren araberakoa da. OpenVPN 2.4-ren build batzuek ez dute --auth-user-pass aintzat hartzen --config aurretik agertzen denean, beraz bi aukera berak beste ordenan konektatzen dira. Jarri direktiba profilean edo komando-lerroan --config ondoren, eta grepeatu profilean agerpen bakoitza beste ezer aldatu aurretik.

auth-nocache mekanismo honi dagokio baina ez du ezer ematen. Bezeroak egiaztagiria memorian zenbat denboran gordetzen duen mugatzen du, eta horrek kraskatu ondoren laguntzen du eta ez du batere laguntzen fitxategia falta denean. Zerbitzariaren aldetik saioaren denbora-muga osteko berriz konektatzeak fitxategia berriro irakurtzen du, beraz abiaraztean funtzionatu zuen egiaztagiri bat egunaren erdian iraungi daiteke.

Kudeaketa-socket-a: gonbite bakoitza, azalera handiagoa

Abiarazi bezeroa entzule batekin eta adierazi esplizituki gonbitak haren gainean jakinaraziko direla, OpenVPN 2.6 eskuliburuan dokumentatutako direktibak erabiliz:

management 127.0.0.1 3030
management-query-passwords

Bash-etik, eduki konexioa ordezko fitxategi-deskriptore batean eta erantzun gonbitearen izenaren arabera, posizioaren arabera beharrean, berriz konektatzeak beste ordena batean galdetu baitiezaioke:

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

Muga garraioa da. Kudeaketa-protokoloa testu soila da TCP gainean loopback-en, beraz entzulea ezin da LAN edo tunel helbidean argitaratu urruneko kontrolatzaile bat irits dadin; urruneko kontrola SSH birbidalketa esan nahi du, ez lotura zabalagoa. Komunitate-daemonak kudeaketa-bezero bakar bat onartzen du aldi berean, beraz GUI edo monitore batek ezin du socket-a zure script-arekin partekatu. Bigarren konexioa ukatua da, ez da ilaran jartzen, eta hutsegitea gorra bihurtu den script baten antza du.

Socket hori kontrol-kanal bat ere bada. Kudeaketa-pasahitzik gabe, 127.0.0.1:3030-ra konektatu daitekeen edozerk irakur dezake egoera, tunela hil edo gonbite bat berak erantzun. Kudeaketa-pasahitza eta egiaztagiri-fitxategia sekretu-klase berekoak dira, eta biek merezi dute ardura bera.

Zein egokitzen zaio inplementazioari

Aukera ezazu egiaztagiri-fitxategia gonbite bakarra kontu-parea denean, bezeroa jabe egonkor batekin zerbitzu gisa exekutatzen denean, eta kontrolatzen ez dituzun babeskopietatik kanpo 600 fitxategi bat edukitzen duzunean. Aukera ezazu kudeaketa-socket-a gako-pasaesaldia edo PKCS#12 pasahitza jokoan dagoenean, bilgarriak prozesua jada gainbegiratzen duenean, edo berriz konektatzea arazten duzun bitartean egoera eta gonbitak ikusi behar dituzunean.

Bi baldintzek mugitzen dute erabakia. Bilgarria /bin/sh bada, binarra zuzenean deitzen duen systemd unitate bat bada edo edukiontzi minimo bat bada, bash-entzako soilik den socket-itsaskina ez dago eskuragarri eta fitxategia da erantzunik merkeena. Sekretua sarritan birakatzen bada, ez da fitxategietako bat ere harentzako etxe ona: galdetu giltza-eraztun bat bilgarri txiki bati eta utzi unitateari bilgarria deitzen, horrek biraketa toki bakarrean uzten baitu eta pasahitza shell-aren historian ez.

Prozesu-ordezkapena bien artean dago eta ez zaio horietako inori dagokio. Beheko lerro bakarrekoak funtzionatzen du bashek openvpn abiatu aurretik hedatzen duelako, ez bezeroak sintaxia ulertzen duelako:

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

Huts egiten du /bin/sh pean, shell-a saihesten duen unitate batean, eta bash edo /dev/fd ez duten irudietan. Gorde proba interaktiboetarako, ez inoiz zerbitzu bat mendeko duen itun gisa.

Babestu sekretua, gero egiaztatu erregistrotik

Bi mekanismoek OpenVPN prozesuarentzat irakurgarria den sekretu bat uzten dute. Ez jarri inoiz pasahitza komando-lerroan edo unitate-fitxategian, non ps-ek eta systemctl-ek tokiko erabiltzaile bakoitzari erakusten dioten; eman fitxategiaren bidea, ez bertako balioa. Ziurtagiriek kontu-parea ordezkatu dezaketen lekuan, horrek gonbite-kategoria kentzen du, ezkutatu beharrean.

Exekuzio zuzen batek gonbiten segida amaitzen dela eta saioa «Initialization Sequence Completed»-era iristen dela erakusten du. Bezeroa gonbite berean gelditzen bada, bat-etortzeak huts egin du: inprimatu socket-ak bidalitako lerro zehatzak, egiaztatu komatxoak eta gonbitearen izena, eta konpondu eredua sleep bat gehitu beharrean. Arrakasta jakinarazten duen eta ezer eramaten ez duen tunela bideratze edo push arazoa da, ez egiaztagiriarena.

Gero probatu berriz konektatzea, ez bakarrik lehen abiaraztea. Bota zerbitzariaren aldetiko saioa edo itxaron haren denbora-muga; bezeroak berriro galdetzen du, eta han erakusten du abiaraztean zuzena zirudien fitxategi batek berriz konektatzen den kontuarentzat oraindik irakurgarria den.