Eroarea de secret invalid vine din container, nu din regula de parolă

Vederea mesajului „secret invalid” produce de obicei o concluzie: VPN-ului nu îi place punctuația. Concluzia este de obicei greșită, pentru că mesajul vine adesea din prelucrarea locală înainte ca vreun gateway să fi privit contul. Două construcții livrează aceeași parolă, un câmp grafic și un fișier de acreditări, și eșuează în locuri diferite. Comparați containerele înainte de a simplifica o parolă care era corectă tot timpul.

Eroarea apare înainte de gateway

Validarea locală, un depozit de secrete blocat, un agent lipsă și un fișier de acreditări malformat produc eșecuri pe care utilizatorul le trăiește ca o singură respingere. Niciunul nu implică serverul de autentificare. Respingerea gateway-ului însuși este un eveniment distinct și vine de obicei cu alt mesaj și alt moment. Ea apare după ce există un tunel și acreditările au fost transmise.

Deci prima întrebare nu este ce caractere sunt legale, ci unde s-a oprit încercarea. Un client care nu a deschis niciodată o conexiune nu a fost respins de nimeni. Notați etapa observată, pentru că fiecare pas ulterior depinde de acea clasificare.

Distincția schimbă și cine repară. O problemă de container aparține dispozitivului și proprietarului, în timp ce o respingere de cont aparține celui care rulează backend-ul de autentificare.

Comparați containerele, nu caracterele

Un câmp de parolă grafic, o intrare în keychain, un fișier de acreditări cu două linii și un secret de automatizare poartă fiecare aceeași valoare într-un alt plic. Plicul are regulile lui, și acele reguli sunt cele care se strică de obicei. Valoarea este rar problema; transportul valorii este. Țineți cele două idei separate și diagnosticul devine mai scurt.

Opțiunile clientului Community OpenVPN 2.6 descriu acel fișier cu două linii pentru auth-user-pass, inclusiv comportamentul când linia parolei lipsește: clientul cere în schimb. Acel singur detaliu explică o clasă de rapoarte de tipul „cere o parolă pe care am furnizat-o deja”. Vă spune și că o a doua linie goală este o stare semnificativă, nu o alegere de formatare inofensivă.

Citarea este din nou un strat separat: ghilimelele dintr-un fișier de acreditări simplu sunt stocate ca date, în timp ce un shell le elimină înainte ca programul să vadă ceva. Același caracter este inofensiv într-un loc și structural în celălalt. Un tabel nu vă poate spune ce container a folosit clientul, așa că citiți configurația clientului înainte de a alege un rând.

Întreruperile de linie sunt și ele structurale. Un fișier cu câmpuri delimitate pe linii nu poate purta o valoare care conține o linie nouă, iar aceasta este o limitare a formatului, nu o judecată despre puterea parolei. Folosiți mecanismul de livrare acceptat de implementare în loc să tăiați secretul ca să încapă într-un fișier improvizat.

Construiți fișierul de acreditări fără daune din shell

Cea mai sigură rută locală ține secretul în afara istoricului shell-ului și a listei de argumente a procesului. Citiți ambele câmpuri interactiv, apoi scrieți cele două linii pe care clientul le așteaptă. Tot restul poate rămâne într-un fișier de configurare ușor de revizuit.

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

Primele două comenzi citesc numele de utilizator și apoi parola fără a o afișa, a treia scrie ambele linii, a patra restricționează fișierul, iar ultima pornește clientul cu acel fișier. Observați că read -r păstrează barele inversate, exact genul de detaliu care transformă o parolă funcțională într-una care eșuează atunci când este omis.

Evitați construirea fișierului cu o variabilă fără ghilimele sau cu un document here plin de expandări de shell. Ambele pot transforma caractere înainte ca ele să ajungă în fișier, iar eșecul rezultat arată ca o respingere VPN pentru că parola de pe disc este într-adevăr diferită de parola pe care o știți. Comparați lungimea în octeți a fișierului cu valoarea așteptată dacă bănuiți asta, fără a tipări secretul. O diferență de unul sau doi octeți este semnătura unui accident de citare.

Citiți etapa din primul mesaj de eroare

Păstrați primul mesaj specific dintr-o încercare și clasificați-l. O eroare de validare locală, o cheie privată lipsă, un agent de secrete indisponibil și o eroare de autentificare a gateway-ului sunt patru rezultate diferite cu patru proprietari diferiți. Doar unul dintre ele este despre cont.

Dacă gateway-ul respinge într-adevăr o acreditare livrată corect, verificați contul, backend-ul de autentificare și orice provocare cerută cu administratorul. O eroare de autentificare generică nu numește un caracter interzis.

Restabiliți valoarea aprobată prin mecanismul corect, în loc să o reduceți la litere și cifre. Politica de parole aparține operatorului, iar o ocolire care o învinge în tăcere nu este o remediere. Ea ascunde și defectul real de la următoarea persoană, care va întâlni aceeași eroare cu o parolă mai slabă și nicio idee mai bună.