OpenVPN auth-nocache: ce se întâmplă la următoarea autentificare

Activați auth-nocache și avertismentul despre memorarea în cache a parolei dispare, împreună cu copia acreditărilor pe care OpenVPN o păstra pentru următoarea renegociere. Dacă asta devine o solicitare, o reîncercare silențioasă sau un tunel întrerupt depinde de unde vin acreditările a doua oară. De aceea este o comparație între forme de implementare, nu un verdict asupra opțiunii. Citiți forma pe care o rulați efectiv înainte de a edita orice profil.

De unde trebuie să vină al doilea set de acreditări

OpenVPN aplică auth-nocache secretelor colectate de auth-user-pass și askpass: după ce sunt folosite, procesul le aruncă în loc să le păstreze pentru următoarea strângere de mână. Renegocierea sosește pe un temporizator, implicit o dată pe oră, așa că a doua cerere sosește mult după ce persoana care a tastat parola a plecat. Acel gol este toată povestea. Cu cache-ul lăsat activ, clientul redă copia salvată fără să întrebe pe nimeni; cu cache-ul dezactivat, trebuie să găsească secretul altundeva sau să eșueze.

Așadar enumerați fiecare loc de unde ar putea veni secretul în acel moment și fiți sincer cu privire la care dintre ele există pe gazdă. O persoană la un terminal, un fișier pe care auth-user-pass sau askpass îl pot citi, sau un token de sesiune emis de server sunt cele trei care contează aici. Dacă niciunul nu este disponibil, renegocierea eșuează o oră după modificare, nu în momentul în care ați făcut-o.

Trei forme, trei puncte de eșec

Un client desktop cu o persoană în față este cazul blând: solicitarea revine, cineva tastează din nou parola, iar costul este atenția. Un serviciu, container sau router care rulează OpenVPN fără terminal este cazul dur, pentru că nu este nimeni să răspundă, iar reconectarea care înainte era silențioasă acum încheie tunelul. Un hibrid se află între cele două și se comportă ca cazul desktop până când dispare sesiunea care putea răspunde solicitării. Ceea ce le desparte nu este dacă există o interfață grafică instalată, ci dacă există o sursă de acreditări în momentul renegocierii.

Mapați-vă implementarea pe una dintre cele trei înainte de a schimba ceva, pentru că sfatul pe care îl găsiți online este aproape întotdeauna scris pentru prima. Aplicarea răspunsului de desktop unui serviciu fără terminal este modul în care un tunel care a funcționat luni de zile începe să cadă în fiecare oră.

Directivă sau flag: alegeți una și știți pe care ați folosit-o

În interiorul unui profil, auth-nocache este o linie separată; într-un apel care numește explicit un profil, este un flag pe acea linie de comandă, iar manualul OpenVPN enumeră ambele forme. Ambele fac același lucru la păstrarea acreditărilor, iar niciuna nu atinge tipul de interfață sau nu repară un avertisment fără legătură din același jurnal. Diferența este persistența: flag-ul acoperă doar acea rulare, așa că un serviciu repornit dintr-un fișier unit sau dintr-un script wrapper nu îl va avea decât dacă wrapper-ul îl transmite și el.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Decideți ce artefact deține setarea, schimbați-o acolo și nicăieri altundeva. Un profil editat pe un laptop plus o unitate systemd care îl suprascrie cu un flag este perechea care produce comportament contradictoriu după o repornire.

Un fișier de acreditări mută secretul în loc să îl șteargă

Îndreptarea auth-user-pass către un fișier oferă o sursă fiecărei renegocieri ulterioare și pune parola într-un loc care supraviețuiește repornirilor. Întrebați cine poate citi acel fișier, dacă demonul îl mai poate citi după ce renunță la privilegii și ce se întâmplă când sistemul de fișiere este montat doar pentru citire sau o vedere de container ascunde calea. Un secret pe disc și un secret în memorie sunt probleme diferite, iar rezolvarea uneia lasă cealaltă la locul ei. Rotația este pasul care se sare: o parolă schimbată pe server dar nu în fișier produce o defecțiune care se citește ca o eroare de rețea.

Păstrați fișierul în proprietatea contului care rulează demonul, lizibil de nimeni altcineva și în afara copiilor de siguranță care părăsesc gazda. Opțiunea auth-gen-token din partea serverului OpenVPN oferă clientului un token de sesiune după o autentificare reușită, ceea ce este un lucru mai mic de lăsat în jur decât parola contului. Scrieți pasul de rotație lângă fișier în orice caz, pentru că fișierul supraviețuiește de obicei persoanei care l-a creat.

Lungirea renegocierii mută costul, nu îl elimină

Cealaltă sugestie este să creșteți reneg-sec până când solicitarea este suficient de rară pentru a fi ignorată. Asta rescrie calendarul de rotație a cheilor sesiunii și împinge aceeași problemă a acreditărilor într-un moment mai târziu și mai puțin previzibil; nu creează o sursă de acreditări. O politică ce reînnoiește cheile după un calendar dintr-un motiv nu ar trebui relaxată doar pentru a evita tastarea unei parole.

Testați reconectarea, nu sesiunea în care stați, pentru că sesiunea vie nu dovedește nimic. Lăsați tunelul să cadă din partea serverului, sau reporniți serviciul clientului, și urmăriți ce face următoarea renegociere fără nimeni la tastatură. Dacă se reconectează, numiți mecanismul care a furnizat secretul; dacă nu, ați găsit costul real al opțiunii pe această gazdă. Oricare rezultat vă dă un răspuns care rezistă în timpul unei întreruperi, nu unul care a rezistat în timpul testelor.

Într-o flotă administrată, proprietarul implementării ar trebui să poată numi trei lucruri: de unde vin acreditările, unde sunt păstrate și cine le rotește. Dacă vreunul dintre aceste răspunsuri este persoana care a configurat gazda, opțiunea nu este încă sigură acolo.