OpenVPN auth-user-pass: fitxategia, stdin edo eskaera? Nola aukeratu

Hiru gauzek erabakitzen dute zein kredentzial-iturri erabili behar duzun: pertsona bat kontsolaren aurrean eserita dagoen, sekretua diskoan bizi daitekeen eta beste prozesu batek eskaerari erantzun behar dion. Gaizki aukeratzen baduzu, bezeroak stdin arazoa salatuko du pasahitza guztiz baliozkoa den bitartean, eta horrek gehienak zerbitzarira bidaltzen ditu arrazoirik gabe. Aukeratu bidea lehenengo; errore-mezuek zentzua dute sortu zituzten bidea dakizunean soilik.

Hori erabakitzen duten hiru baldintzak

Kontsolako eskaera pertsona bat behar duen bide bakarra da, beraz systemd unitate batean edo edukiontzi batean isil-isilik huts egiten duen bakarra da. Pertsona batek bezeroa abiarazi eta pasahitza idazten badu, ez da fitxategirik sartzen eta ezer sentikorrik ez da diskoan geratzen. Bezeroa abioan abiarazten bada, eskaera bera blokeo bihurtzen da, eta denbora-muga, normalean, konexio-hutsegite orokor gisa agertzen da, kredentzialen errore gisa beharrean.

Kredentzialen fitxategia erantzun zuzena da prozesua zaintzarik gabe abiarazten denean eta sekretuak diskoan iraun dezakeenean baimen-multzo kontrolatu baten pean. Sekretua inola ere idatzi behar ez denean - biltegirako soilik politika, iraupen laburreko tokena - bezeroak ireki dezakeen fluxu bat behar duzu, eta horrek praktikan prozesu-ordezkapena edo fitxategi-deskriptore batera idazten duen laguntzaile bat esan nahi du. Kudeaketa-interfazeak laugarren kasua estaltzen du: tunelaren bizi-zikloa jada kudeatzen duen eta socket baten bidez galderei erantzun diezaiekeen kontroladorea.

• Pertsona kontsolaren aurrean, automatizaziorik gabe: eskaera interaktiboa.
• Zaintzarik gabeko abioa, sekretua gorde daiteke: kredentzialen fitxategia 0600 moduarekin.
• Zaintzarik gabeko abioa, sekretua ezin da gorde: prozesu-ordezkapena edo sekretu-agente batek idatzitako fd bat.
• Beste prozesu batek du bezeroa: kudeaketa-interfazea.

Bi erantzunek bat egiten dutenean, aukeratu sekretua argvtik eta shell-historiarik kanpo mantentzen duena. Programaren argumentu gisa emandako pasahitza edozein tokiko erabiltzailek irakur dezake prozesuen zerrendaren bidez, eta zail da esposizio hori desegitea.

Zer egiten duen sarrera-bide bakoitzak benetan

--auth-user-pass bere horretan kontsolako erabiltzaile-izena eta pasahitza eskatzen ditu. Fitxategi-izen bat emanda, bezeroak lehenengo lerroa erabiltzaile-izen gisa hartzen du eta bigarrena pasahitz gisa; ezerk ez du komatxorik, iruzkinik edo gako-balio sintaxirik onartzen. Hori da formatu osoa, beraz, INI fitxategi bat espero duela editatzen duenak hondatzen du. Lerroan txertatutako <auth-user-pass> bloke batek bi lerro berberak ditu profilean, eta horrek profila bera sekretu bihurtzen du eta gako pribatu baten tratamendu-klase berean jartzen du.

Beste bi bideak fluxu bat eta socket bat dira. OpenVPN irakurgarria den fitxategi-deskriptore bat behar du soilik, beraz prozesu-ordezkapen bat, hodiz eutsitako /dev/fd sarrera bat edo benetan FIFO den fitxategi-izen bat onartuko du. Kudeaketa-interfazea izatez ezberdina da: bezeroak gainbegiratzen duen prozesu bati galdetzen dio balioak, berak irakurri beharrean. Aldea garrantzitsua da berriz konektatzean: kredentzialen fitxategi batek, sekretu-laguntzaile batek berriro idatz dezakeen FIFO batek eta kudeaketa-interfazeak pertsona gabe hornitu dezakete berriro; prozesu-ordezkapenak ezin du, deskriptorea lehen irakurketan kontsumitzen delako.

Fitxategiak zehazki bi lerro izan behar ditu

Hutsegite-modu bik estaltzen dute kredentzialen fitxategi hautsi gehienak. Windows editore batek CRLF amaierak uzten ditu, itzulera-karakterea pasahitzaren parte bihurtzen da eta zerbitzariak pantailan zuzena dirudien balioa ukatzen du. Bigarren lerro huts batek - pasahitza egon behar lukeen lekuan lerro huts batek - bezeroa pasahitz huts batekin uzten du, eta zerbitzariak ukatzen du pantailako balioa zuzena dirudien arren. Pasahitzaren ondorengo lerro-jauzi gehigarri bat kaltegabea da. Idatzi fitxategia shell-etik, ez editore batetik, eta egiaztatu byteak:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Bideak edukia adina axola du. Bide erlatibo bat prozesuaren lan-direktorioarekiko ebazten da, eta zerbitzu batentzat hori gutxitan da probatu zenuen direktorioa. Erabili bide absolutua, egin fitxategia bezeroa exekutatzen duen kontuaren jabetzakoa eta eduki 0600 modua, taldeak eta besteek irakur ez dezaten. OpenVPN 2.6 eskuliburuak direktibaren onartutako formak zerrendatzen ditu; egiaztatu hirugarren bat asmatu aurretik.

Probatu fitxategia zerbitzaria erruduntzatu aurretik. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 exekutatzeak fitxategia ireki zen ala ez eta, geroago, kredentzialak onartu ziren ala ez inprimatzen du, eta horrek esaten dizu zein geruza aldatu hurrena.

Fluxuak, stdin eta sortzen dituzten erroreak

Pasahitza hodi bidez pasatzea da gehienek lehenengo probatzen dutena eta sorpresa gehien duen bidea. Prozesu-ordezkapenak funtzionatzen du bezeroak deskriptore irakurgarri bat soilik behar duelako: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin pasatzeak solik funtzionatzen du bezeroak galdetzen duen unean stdin oraindik irekita eta irakurgarria dagoenean, eta hori ez da egia jadanik kontsumitu duen hodi batean.

ERROR: could not read Auth username from stdin-ek bi kausa desberdin ditu. 2.3.x bezero batzuetan mezua stdin kudeaketaren akats batetik zetorren eta 2.3 bertsio berriagoek konpondu zuten, beraz hain bezero zaharra eguneratuta soilik hobetzen da. Egungo bezero batean, idazkera berak esan nahi du bezeroak kontsola-sarrera eskatu zuela eta stdin ez zela terminal bat - hain zuzen systemd unitate batean, cron zeregin batean edo -t gabe abiarazitako edukiontzi batean gertatzen den egoera.

auth-nocache-ek hirugarren begizta bat gehitzen du, pasahitz hautsi baten itxura duena. Erabili ondoren kredentzialak memoriatik botatzen ditu, beraz sare-aldaketa batek eragindako berriz konektatzeak ez du ezer berriz erreproduzitzeko eta eskaera itzultzen da. Hori da direktiba diseinatu bezala funtzionatzen. auth-nocache-ek bezeroak memorian gordetzen duena aldatzen du, ez zerbitzariak edo identitate-hornitzaileak kontuari buruz pentsatzen duena, beraz konponbide osoa fitxategi bera berriro hornitzea da, berrabiaraztean berriro irakurrita - eta kudeatutako konexio baterako hornidura hori onartutako sekretu-biltegitik etorri behar da, ez script bateko pasahitz batetik.

Kudeaketa-interfazea beste prozesu batek eskaera duenean

Tunela jada gainbegiratzen duen kontroladore batek haren galderei ere erantzun diezaieke. Abiarazi bezeroa --management 127.0.0.1 7505-rekin, irakurri egoera-lerroak eta erreparatu >PASSWORD:Need 'Auth' username/password-ri. Kontroladoreak username "Auth" alice-rekin erantzuten du, ondoren password "Auth" ... komando-lerro bereizietan. 'Auth' tokenak eskaeraren identifikatzailea oihartzun egiten du eta bat etorri behar du, bestela erantzuna ezikusi egiten da eta bezeroa itxaroten geratzen da.

Kostua orain duzun egoera-makina bat da: konexio-ordena, bezeroaren berrabiarazteak eta ostalarian beste erabiltzaileek iritsi behar ez duten socket lokal bat. Erosten duzuna exekuzio-denboran hornitutako kredentziala da, diskoan fitxategirik gabe eta blokea daitekeen eskaerarik gabe. Zure pilan beste ezerk protokoloa hitz egiten ez badu, bide honek mantendu beharreko osagai bat gehitzen du.

Kredentzial-arazo diruditen hutsegiteak

Inoiz amaitzen ez den TLS esku-ukaldi bat, edo VERIFY ERROR: depth=0, error=certificate signature failure bat, konfiantza-arazoa da eta edozein erabiltzaile-izen irakurri aurretik gertatzen da. UDP entzule batera zuzendutako proto tcp bezero bat leku berean huts egiten du: paketeak ez dira inoiz autentifikazio-fasera iristen, beraz pasahitz guztiek oker dirudite elkartzeagatik. Euts iezaiozu ziurtagirien egiaztapenari kredentziala bidali aurretik; eskaera ezagun batek ez du ezer esaten pasahitza nori iristen zaion. Egiaztatu ziurtagirien katea, izen arrunta eta garraioa kredentziala ukitu aurretik.

Profila muntatzen duen script-eko shell akatsak dira beste arrasto faltsua. [ ! -f "$file" ] barruan falta den zuriune batek command not found sortzen du, script goiz gelditzen da, profila ez da inoiz berreraikitzen eta bezeroa aurrekoarekin abiarazten da. Akats hori shell-ari dagokio, ez autentifikazioari, eta alferrik da pasahitza berridaztea hura ezabatzeko.

Fluxu honetako eskaera guztiak ez dira kredentzial hau. Gako pribatuaren pasaesaldi bat, HTTP proxy saio-hasiera bat eta zerbitzuaren pasahitza fase desberdinetan eskatzen diren hiru sekretu desberdin dira, eta gako-pasaesaldia normalean bezeroak edo agente batek kudeatzen du, ez auth-user-passek. Eskaera TLS saioa prest egon aurretik agertzen bada, galdera okerra erantzuten ari zara eta kontua berrezartzeak ez du lagunduko. Eskaera okerra baztertuta, gainerako egiaztapenak geruzarik goiztiarrenetik hasten dira:

• Irakurri lehen protokolo-errorea, ez azken kredentzial-lerroa: TLS, gero autentifikazioa, gero push.
• Egiaztatu fitxategiak bi lerro dituela, ez duela itzulera-karaktererik eta bide absolutu batekin erreferentziatzen dela.
• Egiaztatu profilak eta komando-lerroak ez dutela direktibaren inguruan desadostasunik.
• Bereizi "kredentzialak onartuta" eta "trafikoa dabil" - bideratzea eta DNS geruza berantiarragoa dira.

Bezeroa push fasera iristen denean, utzi kredentzialak begiratzeari eta hasi zerbitzariak bidalitako bideak eta DNS zerbitzariak irakurtzen. Hori da hurrengo arazoa, eta ez du zerikusirik oraintxe konpondu duzun pasahitzarekin.