OpenVPN auth-user-pass: skedar, stdin apo kërkesë? Si të zgjidhni

Tre gjëra vendosin se cilën burim kredencialesh të përdorni: nëse një person është ulur në konsolë, nëse sekreti mund të jetojë në disk dhe nëse një proces tjetër duhet t'i përgjigjet kërkesës. Nëse zgjidhni gabimisht, klienti raporton një problem me stdin ndërsa fjalëkalimi është plotësisht i vlefshëm, dhe kjo i dërgon shumicën në server pa arsye. Zgjidhni më parë rrugën; mesazhet e gabimit kanë kuptim vetëm pasi të dini cila rrugë i prodhoi.

Tre kushtet që e vendosin

Kërkesa në konsolë është rruga e vetme që kërkon një person, prandaj është e vetmja që dështon në heshtje në një njësi systemd ose në një kontejner. Nëse një person nis klientin dhe shkruan fjalëkalimin, nuk përfshihet asnjë skedar dhe asgjë e ndjeshme nuk përfundon në disk. Nëse klienti niset gjatë boot-it, e njëjta kërkesë bëhet një bllokim, dhe afati kohor zakonisht shfaqet si një dështim i përgjithshëm lidhjeje dhe jo si gabim kredencialesh.

Një skedar kredencialesh është përgjigja e saktë kur procesi niset pa mbikëqyrje dhe sekreti mund të mbijetojë në disk nën një grup të kontrolluar lejesh. Kur sekreti nuk duhet shkruar fare - një politikë vetëm kasafortë, një token afatshkurtër - ju nevojitet një rrymë që klienti mund të hapë, që në praktikë do të thotë zëvendësim procesi ose një ndihmës që shkruan në një përshkrues skedari. Ndërfaqja e administrimit mbulon rastin e katërt: një kontrollues që tashmë menaxhon ciklin e jetës së tunelit dhe mund t'u përgjigjet pyetjeve përmes një socket.

• Person në konsolë, pa automatizim: kërkesë interaktive.
• Nisje pa mbikëqyrje, sekreti mund të ruhet: skedar kredencialesh me modalitetin 0600.
• Nisje pa mbikëqyrje, sekreti nuk mund të ruhet: zëvendësim procesi ose një fd ku shkruan një agjent sekretesh.
• Një proces tjetër zotëron klientin: ndërfaqja e administrimit.

Kur përshtaten dy përgjigje, zgjidhni atë që e mban sekretin jashtë argv dhe jashtë historikut të shell-it. Një fjalëkalim i kaluar si argument programi është i lexueshëm nga çdo përdorues lokal përmes listës së proceseve, dhe ai ekspozim është i vështirë për t'u anuluar.

Çfarë bën në të vërtetë secila rrugë hyrëse

--auth-user-pass vetëm kërkon në konsolë një emër përdoruesi dhe një fjalëkalim. Kur i jepet një emër skedari, klienti merr rreshtin e parë si emër përdoruesi dhe rreshtin e dytë si fjalëkalim; asgjë nuk mbështet thonjëza, komente ose sintaksë çelës-vlerë. Ky është i gjithë formati, prandaj kushdo që e modifikon duke pritur një skedar INI e prish atë. Një bllok <auth-user-pass> në linjë mban të njëjtat dy rreshta brenda profilit, gjë që e bën vetë profilin një sekret dhe e vendos në të njëjtën klasë trajtimi si një çelës privat.

Dy rrugët e tjera janë një rrymë dhe një socket. OpenVPN ka nevojë vetëm për një përshkrues skedari të lexueshëm, kështu që do të pranojë një zëvendësim procesi, një hyrje /dev/fd të mbështetur nga një tub ose një emër skedari që në të vërtetë është FIFO. Ndërfaqja e administrimit është e ndryshme në natyrë: klienti i kërkon një procesi mbikëqyrës vlerat në vend që t'i lexojë vetë. Ky ndryshim ka rëndësi në rilidhje: një skedar kredencialesh, një FIFO në të cilin një ndihmës sekretesh mund të shkruajë përsëri dhe ndërfaqja e administrimit mund të furnizojnë përsëri pa një person; zëvendësimi i procesit nuk mundet, sepse përshkruesi konsumohet në leximin e parë.

Skedari duhet të ketë saktësisht dy rreshta

Dy mënyra dështimi mbulojnë shumicën e skedarëve të kredencialeve të prishur. Një redaktues i Windows lë mbarime CRLF, kthimi i karrocës bëhet pjesë e fjalëkalimit dhe serveri refuzon një vlerë që duket e saktë në ekran. Një rresht i dytë bosh - një rresht bosh aty ku duhet të jetë fjalëkalimi - e lë klientin me një fjalëkalim bosh, të cilin serveri e refuzon edhe pse vlera në ekran duket e saktë. Një rresht i ri shtesë pas fjalëkalimit është i padëmshëm. Shkruajeni skedarin nga shell-i, jo nga një redaktues, dhe kontrolloni bajtët:

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

Rruga ka po aq rëndësi sa përmbajtja. Një rrugë relative zgjidhet kundrejt drejtorisë së punës së procesit, e cila për një shërbim rrallë është drejtoria ku keni testuar. Përdorni një rrugë absolute, bëjeni skedarin pronë të llogarisë që ekzekuton klientin dhe mbani modalitetin 0600 që grupi dhe të tjerët të mos mund ta lexojnë. Manuali i OpenVPN 2.6 rendit format e pranuara të direktivës; kontrollojeni përpara se të shpikni një të tretë.

Testoni skedarin përpara se të fajësoni serverin. Ekzekutimi i openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 printon nëse skedari u hap dhe, më vonë, nëse kredencialet u pranuan, gjë që ju tregon cilën shtresë të ndryshoni më tej.

Rrymat, stdin dhe gabimet që prodhojnë

Kalimi i fjalëkalimit përmes një tubi është gjëja e parë që provojnë shumica dhe rruga me më shumë surpriza. Zëvendësimi i procesit funksionon sepse klienti ka nevojë vetëm për një përshkrues të lexueshëm: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Kalimi i /dev/stdin funksionon vetëm kur stdin është ende i hapur dhe i lexueshëm në momentin që klienti pyet, gjë që nuk është e vërtetë në një tub që e ka konsumuar tashmë.

ERROR: could not read Auth username from stdin ka dy shkaqe të ndryshme. Në disa klientë 2.3.x mesazhi vinte nga një defekt i trajtimit të stdin që e rregulluan versionet 2.3 të mëvonshme, prandaj një klient kaq i vjetër përmirësohet vetëm duke u përditësuar. Në një klient aktual i njëjti formulim do të thotë që klienti kërkoi hyrje nga konsola dhe stdin nuk ishte terminal - pikërisht situata në një njësi systemd, një detyrë cron ose një kontejner i nisur pa -t.

auth-nocache shton një cikël të tretë që duket si fjalëkalim i prishur. I hedh kredencialet nga memoria pas përdorimit, kështu që një rilidhje e shkaktuar nga një ndryshim rrjeti nuk ka çfarë të riprodhojë dhe kërkesa kthehet. Ky është direktiva që punon siç është projektuar. auth-nocache ndryshon atë që klienti mban në memorie, jo atë që serveri ose ofruesi i identitetit mendon për llogarinë, prandaj e gjithë rregullimi është të furnizohet përsëri i njëjti skedar, i rilexuar në rinisje - dhe për një lidhje të menaxhuar ai furnizim duhet të vijë nga depoja e miratuar e sekreteve, jo nga një fjalëkalim në një skript.

Ndërfaqja e administrimit kur një proces tjetër zotëron kërkesën

Një kontrollues që tashmë mbikëqyr tunelin mund t'u përgjigjet edhe pyetjeve të tij. Nisni klientin me --management 127.0.0.1 7505, lexoni rreshtat e statusit dhe vëzhgoni >PASSWORD:Need 'Auth' username/password. Kontrolluesi përgjigjet me username "Auth" alice të ndjekur nga password "Auth" ... në rreshta komandash të veçantë. Tokeni 'Auth' përsërit identifikuesin nga kërkesa dhe duhet të përputhet, përndryshe përgjigja injorohet dhe klienti pret.

Kostoja është një makinë gjendjesh që tani ju zotëroni: rendi i lidhjeve, rinisjet e klientit dhe një socket lokal të cilin përdoruesit e tjerë në host nuk duhet ta arrijnë. Ajo që blini është një kredencial i furnizuar në kohën e ekzekutimit, pa skedar në disk dhe pa një kërkesë që mund të bllokohet. Nëse asgjë tjetër në stivin tuaj nuk flet tashmë këtë protokoll, kjo rrugë shton një komponent për t'u mirëmbajtur.

Dështime që duken si probleme kredencialesh

Një shtrëngim duarsh TLS që nuk përfundon kurrë, ose një VERIFY ERROR: depth=0, error=certificate signature failure, është një problem besimi dhe ndodh përpara se të lexohet ndonjë emër përdoruesi. Një klient proto tcp i drejtuar drejt një dëgjuesi UDP dështon në të njëjtin vend: paketat nuk arrijnë kurrë në fazën e vërtetimit, prandaj çdo fjalëkalim duket i gabuar për shkak të shoqërimit. Mbani verifikimin e certifikatave të ndezur përpara se kredenciali të dërgohet; një kërkesë e njohur nuk thotë asgjë për atë se kush e merr fjalëkalimin. Kontrolloni zinxhirin e certifikatave, emrin e përbashkët dhe transportin përpara se të prekni kredencialin.

Gabimet e shell-it në skriptin që monton profilin janë gjurma tjetër e rreme. Një hapësirë që mungon brenda [ ! -f "$file" ] prodhon command not found, skripti ndalon herët, profili nuk rindërtohet kurrë dhe klienti niset me atë të mëparshëm. Ai gabim i përket shell-it, jo vërtetimit, dhe sado herë ta rishkruani fjalëkalimin, nuk e fshin atë.

Jo çdo kërkesë në këtë rrjedhë është ky kredencial. Fraza e kalimit e një çelësi privat, hyrja përmes proxy-t HTTP dhe fjalëkalimi i shërbimit janë tre sekrete të ndryshme të kërkuara në faza të ndryshme, dhe fraza e kalimit e çelësit zakonisht trajtohet nga klienti ose një agjent në vend të auth-user-pass. Nëse kërkesa shfaqet përpara se sesioni TLS të jetë ngritur, ju po i përgjigjeni pyetjes së gabuar dhe asnjë rivendosje llogarie nuk do të ndihmojë. Pasi kërkesa e gabuar përjashtohet, kontrollet e mbetura fillojnë nga shtresa më e hershme:

• Lexoni gabimin e parë të protokollit, jo rreshtin e fundit të kredencialeve: TLS, pastaj vërtetimi, pastaj push.
• Konfirmoni që skedari ka dy rreshta, nuk përmban kthime karroce dhe referohet me një rrugë absolute.
• Konfirmoni që profili dhe rreshti i komandës nuk kundërshtojnë njëri-tjetrin për direktivën.
• Ndani "kredencialet u pranuan" nga "trafiku rrjedh" - rrugëtimi dhe DNS janë një shtresë e mëvonshme.

Kur klienti arrin fazën push, ndaloni së shikuari kredencialet dhe filloni të lexoni rrugët dhe serverët DNS që dërgoi serveri. Ai është problemi tjetër, dhe nuk ka asnjë lidhje me fjalëkalimin që sapo rregulluat.