Kur shfaqet «invalid secrets», zakonisht kjo të çon në një përfundim: VPN-së nuk i pëlqejnë shenjat e pikësimit. Ky përfundim zakonisht është i gabuar, sepse mesazhi shpesh vjen nga trajtimi lokal përpara se ndonjë portë të ketë parë llogarinë. Dy modele dërgojnë të njëjtin fjalëkalim, një fushë grafike dhe një skedar kredencialesh, dhe dështojnë në vende të ndryshme. Krahasoni kontejnerët përpara se të thjeshtoni një fjalëkalim që ishte në rregull gjatë gjithë kohës.

Gabimi vjen përpara portës

Vërtetimi lokal, një depo sekretesh e kyçur, një agjent që mungon dhe një skedar kredencialesh i keqformuar të gjitha prodhojnë dështime që përdoruesi i përjeton si një refuzim. Asnjëra prej tyre nuk përfshin serverin e vërtetimit. Refuzimi i vetë portës është një ngjarje e veçantë dhe zakonisht vjen me një mesazh dhe një kohë të ndryshme. Ndodh pasi ekziston një tunel dhe kredencialet janë transmetuar.

Pra, pyetja e parë nuk është cilat karaktere lejohen, por ku u ndal përpjekja. Një klient që nuk hapi kurrë një lidhje nuk është refuzuar nga askush. Shkruani fazën që keni vëzhguar, sepse çdo hap i mëvonshëm varet nga ky klasifikim.

Dallimi ndryshon edhe kush e rregullon. Një problem kontejneri i takon pajisjes dhe pronarit të saj, ndërsa një refuzim llogarie i takon atij që drejton backend-in e vërtetimit.

Krahasoni kontejnerët, jo karakteret

Një fushë grafike fjalëkalimi, një zë në keychain, një skedar kredencialesh me dy rreshta dhe një sekret automatizimi secili mbart të njëjtën vlerë në një zarf tjetër. Zarfi ka rregullat e veta dhe pikërisht ato rregulla zakonisht thyhen. Vlera rrallë është problemi; transporti i vlerës është. Mbani të ndara dy idetë dhe diagnoza bëhet më e shkurtër.

Ku ndalon vleraÇfarë shihniÇfarë kontrolloniKush e zotëron rregullimin
Fushë grafike ose profil i menaxhuarNjë mesazh validimi përpara se të hapet ndonjë lidhjeMënyra e zgjedhur e vërtetimit dhe nëse fusha mban sekretin apo emrin e përdoruesitPronari i pajisjes ose autori i profilit
Keychain ose agjent sekreteshNjë kërkesë që rikthehet vazhdimisht, ose një gabim agjentiNëse agjenti është i shkyçur dhe mban një zë për këtë profilPërdoruesi që zotëron keychain-in
Skedar kredencialesh me dy rreshtaNjë kërkesë për një fjalëkalim që tashmë është dhënëNumri i rreshtave, rendi i rreshtave dhe nëse është i pranishëm një rresht i ri në fundKushdo që gjeneroi skedarin
Argument shell-i ose mjedisPunon në mënyrë interaktive, por dështon në automatizimNëse shell-i e zgjeroi, e preu ose e regjistroi vlerënKushdo që shkroi automatizimin

Opsionet zyrtare të klientit Community OpenVPN 2.6 përshkruajnë atë skedar me dy rreshta për auth-user-pass, duke përfshirë sjelljen kur rreshti i fjalëkalimit mungon: klienti kërkon në vend të tij. Ky detaj i vetëm shpjegon një klasë raportesh «kërkon një fjalëkalim që e dhashë tashmë». Ai gjithashtu tregon se një rresht i dytë bosh është një gjendje kuptimplote dhe jo një zgjedhje e padëmshme formatimi.

Thonjëzimi është përsëri një shtresë e veçantë: thonjëzat brenda një skedari të thjeshtë kredencialesh ruhen si të dhëna, ndërsa shell-i i heq ato përpara se programi të shohë ndonjë gjë. I njëjti karakter është i padëmshëm në një vend dhe strukturor në tjetrin. Një tabelë nuk mund t'ju thotë se cilin kontejner përdori klienti juaj, prandaj lexoni konfigurimin e vetë klientit përpara se të zgjidhni një rresht.

Ndërprerjet e rreshtave janë gjithashtu strukturore. Një skedar me fusha të ndara me rreshta nuk mund të mbajë një vlerë që përmban një rresht të ri, dhe ky është një kufizim i formatit, jo një gjykim për forcën e fjalëkalimit. Përdorni mekanizmin e dorëzimit të mbështetur nga vendosja, në vend që ta shkurtoni sekretin për t'u përshtatur me një skedar të improvizuar.

Ndërtoni skedarin e kredencialeve pa dëmtim nga shell-i

Rruga më e sigurt lokale e mban sekretin jashtë historikut të shell-it dhe jashtë listës së argumenteve të procesit. Lexoni të dyja fushat në mënyrë interaktive dhe më pas shkruani dy rreshtat që pret klienti. Çdo gjë tjetër mund të mbetet në një skedar konfigurimi që është i lehtë për t'u rishikuar.

read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds

Dy komandat e para lexojnë emrin e përdoruesit dhe më pas fjalëkalimin pa e shfaqur, e treta shkruan të dy rreshtat, e katërta kufizon skedarin dhe e fundit nis klientin me atë skedar. Vini re se read -r ruan backslash-et, që është pikërisht lloji i detajit që e kthen një fjalëkalim funksional në një të dështuar kur hiqet.

Shmangni ndërtimin e skedarit me një variabël pa thonjëza ose me një here-dokument plot me zgjerime të shell-it. Të dyja mund t'i transformojnë karakteret përpara se të arrijnë në skedar, dhe dështimi që rezulton duket si refuzim i VPN-së, sepse fjalëkalimi në disk është vërtet i ndryshëm nga ai që njihni. Nëse e dyshoni këtë, krahasoni gjatësinë në bajt të skedarit me vlerën e pritur, pa e printuar vetë sekretin. Një mospërputhje prej një ose dy bajteve është nënshkrimi i një aksidenti me thonjëzat.

Lexoni fazën nga gabimi i parë

Mbani mesazhin e parë specifik nga një përpjekje dhe më pas klasifikojeni. Një gabim validimi lokal, një çelës privat që mungon, një agjent sekretesh i padisponueshëm dhe një dështim vërtetimi në portë janë katër rezultate të ndryshme me katër pronarë të ndryshëm. Vetëm njëri prej tyre ka të bëjë me llogarinë.

Nëse porta vërtet po refuzon një kredencial të dorëzuar saktë, kontrolloni llogarinë, backend-in e vërtetimit dhe çdo sfidë të kërkuar me administratorin. Një dështim i përgjithshëm vërtetimi nuk emërton një karakter të ndaluar.

Riktheni vlerën e miratuar përmes mekanizmit të duhur, në vend që ta reduktoni në shkronja dhe shifra. Politika e fjalëkalimeve i takon operatorit, dhe një zgjidhje që e thyen atë në heshtje nuk është rregullim. Ajo e fsheh edhe defektin e vërtetë nga personi i ardhshëm, i cili do të hasë të njëjtin gabim me një fjalëkalim më të dobët dhe pa asnjë ide më të mirë.

Artikuj të ngjashëm