Skedari i kredencialeve apo soketi i menaxhimit të OpenVPN: cilin të skriptosh
auth-user-pass mbulon kërkesën e llogarisë; soketi i menaxhimit mbulon të katërtat. Krahasoni ekspozimin, koston e skriptit dhe si dështon secili në një shërbim.
Një skript që nis OpenVPN dhe nuk lidhet kurrë zakonisht nuk është problem rrjeti: klienti qëndron te një kërkesë pa terminal ku ta vizatojë. OpenVPN ka saktësisht dy mënyra të mbështetura për t'iu përgjigjur asaj kërkese pa një njeri, një skedar kredencialesh pas auth-user-pass dhe soketi i menaxhimit, dhe ato nuk janë të këmbyeshme. Skedari kushton një direktivë dhe përgjigjet një kërkese; soketi përgjigjet çdo kërkese dhe i jep çdo gjëje që mund të hapë një port loopback një kanal kontrolli të paautentikuar. Cili i përket vendosjes suaj varet nga ajo se cila kërkesë po bllokon vërtet, dhe nga ajo se çfarë sekreti mund të përballoni ta lini në qetësi.
Emërto kërkesën para se të zgjedhësh një mekanizëm
Katër kërkesa duken njësoj në një terminal. Çifti i llogarisë vjen nga konfigurimi PAM ose auth-user-pass-verify i serverit dhe përgjigjet nga auth-user-pass. Fraza e fjalëkalimit të një çelësi privat i përket skedarit të çelësit dhe lexohet përmes --askpass ose shtypet me dorë. Një paketë PKCS#12 kërkon fjalëkalimin e vet. Autentikimi i përfaqësuesit përdor skedarin auth që merr --http-proxy, jo kredencialet e llogarisë.
Kur OpenVPN ekzekutohet si fëmijë i systemd, PHP ose Node nuk ka terminal, kështu që secila prej tyre bllokon në heshtje. Procesi qëndron aty, regjistri ndalon pas rreshtit të shifrimit dhe njësia përfundimisht skadon; ai heshtje është arsyeja pse njerëzit shtojnë një cikël riprovimi ose një sleep në vend që të shohin cila kërkesë është në pritje. Vetëm soketi i menaxhimit mund t'u përgjigjet të katërve. Skedari i kredencialeve përgjigjet të parit dhe asgjë tjetër.
auth-user-pass: një skedar, një kërkesë
Skedari mban emrin e përdoruesit në rreshtin e parë dhe fjalëkalimin në të dytin, dhe asgjë tjetër: pa thonjëza, pa emra çelësash, pa koment. Vendos modalitetin 600 dhe bëj pronar llogarinë që ekzekuton openvpn, e cila për një shërbim është shpesh një përdorues i dedikuar dhe jo hyrja juaj. Një skedar në pronësi të root nën /root është ndryshimi midis një komande që funksionon në shellin tuaj dhe një njësie që dështon në nisje.
Dy detaje e kthejnë një skedar të saktë në një kërkesë. Një redaktor që ruan CRLF lë një kthim karroce të ngjitur pas fjalëkalimit, kështu që serveri refuzon një fjalëkalim që në skedar duket i saktë; kontrollo me cat -A ose od -c në vend të syrit. Dhe një auth-user-pass pa argument brenda profilit do të thotë sipas dizajnit «pyet përdoruesin», të cilin një direktivë e dytë në rreshtin e komandës mund të mos e anulojë, sepse profili analizohet aty ku ndodhet.
Rendi i opsioneve është kurthi i tretë, dhe varet nga versioni. Disa ndërtime të OpenVPN 2.4 injorojnë --auth-user-pass kur shfaqet para --config, kështu që të njëjtat dy opsione në rendin tjetër lidhen. Vendos direktivën brenda profilit, ose pas --config në rreshtin e komandës, dhe kërko në profil çdo dukuri para se të ndryshosh diçka tjetër.
auth-nocache i përket këtij mekanizmi por nuk siguron asgjë. Kufizon sa kohë klienti e mban kredencialin në memorie, gjë që ndihmon pas një rrëzimi dhe aspak kur skedari mungon. Një rilidhje pas skadimit të sesionit në anën e serverit e rilexon skedarin, kështu që një kredencial që punoi në nisje mund të skadojë në mes të ditës.
Soketi i menaxhimit: çdo kërkesë, më shumë sipërfaqe
Nis klientin me një dëgjues dhe deklaro shprehimisht se kërkesat do të raportohen mbi të, duke përdorur direktivat e dokumentuara në manualin e OpenVPN 2.6:
management 127.0.0.1 3030
management-query-passwords
Nga bash mbaj lidhjen në një përshkrues skedari të lirë dhe përgjigju sipas emrit të kërkesës, jo sipas pozicionit, sepse një rilidhje mund të pyesë në një rend tjetër:
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
Kufiri është transporti. Protokolli i menaxhimit është tekst i thjeshtë mbi TCP në loopback, kështu që dëgjuesi nuk duhet të publikohet në një adresë LAN ose tuneli që një kontrollues i largët ta arrijë; një kontrollues i largët do të thotë një përcjellje SSH, jo një lidhje më e gjerë. Daemoni i komunitetit pranon gjithashtu vetëm një klient menaxhimi në një kohë, kështu që një GUI ose një monitor nuk mund ta ndajnë soketin me skriptin tuaj. Lidhja e dytë refuzohet, nuk vihet në radhë, dhe dështimi duket si një skript që është shurdhuar.
Ai soket është gjithashtu një kanal kontrolli. Pa një fjalëkalim menaxhimi, çdo gjë që mund të lidhet me 127.0.0.1:3030 mund të lexojë statusin, të vrasë tunelin ose t'i përgjigjet vetë një kërkese. Fjalëkalimi i menaxhimit dhe skedari i kredencialeve janë sekrete të së njëjtës klasë, dhe të dy meritojnë të njëjtin kujdes.
Cili i përshtatet vendosjes
Zgjidh skedarin e kredencialeve kur e vetmja kërkesë është çifti i llogarisë, klienti ekzekutohet si shërbim me një pronar të qëndrueshëm, dhe mund të mbash një skedar 600 jashtë kopjeve rezervë që nuk i kontrollon. Zgjidh soketin e menaxhimit kur është në lojë një frazë fjalëkalimi çelësi ose një fjalëkalim PKCS#12, kur mbështjellësi tashmë mbikëqyr procesin, ose kur duhet të vëzhgosh statusin dhe kërkesat ndërsa korrigjosh një rilidhje.
Dy kushte e lëvizin vendimin. Nëse mbështjellësi është /bin/sh, një njësi systemd që thërret binarin drejtpërdrejt, ose një kontejner minimal, ngjitësi i soketit vetëm për bash nuk është i disponueshëm dhe skedari është përgjigja më e lirë. Nëse sekreti rrotullohet shpesh, asnjë skedar nuk është shtëpi e mirë për të: pyet një unazë çelësash nga një mbështjellës i vogël dhe lëre njësinë të thërrasë mbështjellësin, gjë që e mban rrotullimin në një vend dhe fjalëkalimin jashtë historisë së shellit.
Zëvendësimi i proceseve qëndron midis të dyjave dhe nuk i përket asnjërës. Rreshti i vetëm më poshtë funksionon sepse bash e zgjeron para se openvpn të nisë, jo sepse klienti e kupton sintaksën:
openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")
Ai thyhet nën /bin/sh, në një njësi që e anashkalon shellin, dhe në imazhe pa bash ose /dev/fd. Mbaje për testime interaktive, kurrë si kontrata nga e cila varet një shërbim.
Mbro sekretin, pastaj verifiko nga regjistri
Të dy mekanizmat lënë një sekret të lexueshëm nga procesi OpenVPN. Kurrë mos e vendos fjalëkalimin në rreshtin e komandës ose në skedarin e njësisë, ku ps dhe systemctl ia tregojnë çdo përdoruesi lokal; kalo rrugën drejt skedarit, jo vlerën brenda tij. Aty ku certifikatat mund të zëvendësojnë çiftin e llogarisë, kjo e heq kategorinë e kërkesës në vend që ta fshehë.
Një ekzekutim i saktë tregon sekuencën e kërkesave që përfundon dhe sesionin që arrin «Initialization Sequence Completed». Nëse klienti ndalon te e njëjta kërkesë, përputhja dështoi: printo rreshtat e saktë që dërgoi soketi, kontrollo thonjëzat dhe emrin e kërkesës, dhe rregullo modelin në vend që të shtosh një sleep. Një tunel që raporton sukses dhe nuk mbart asgjë është problem rrugëtimi ose push, jo kredencialesh.
Pastaj testo rilidhjen, jo vetëm nisjen e parë. Ndërpre sesionin në anën e serverit ose prit skadimin e tij; klienti pyet përsëri, dhe aty një skedar që dukej i saktë në nisje tregon nëse është ende i lexueshëm nga llogaria që rilidhet.