OpenVPN fără certificat de client: politică de server, nu profil

Ștergeți liniile de certificat și cheie, predați profilul, iar conexiunea tot eșuează cu o eroare de certificat. Profilul nu a fost niciodată ceea ce impunea această cerință. Serverul decide dacă un certificat de client este obligatoriu și nicio modificare pe partea clientului nu negociază asta. Deci remedierea este o schimbare a politicii serverului, făcută deliberat, cu tot ce depinde de ea actualizat în aceeași trecere.

Profilul nu este politica

Community OpenVPN 2.6 vine cu certificate de client obligatorii, deoarece verify-client-cert are implicit valoarea require. Setarea lui la none este cea care oprește cerința unui certificat și predă autentificarea clientului acelei aranjamente de nume de utilizator și parolă pe care serverul o rulează deja. Ghidurile mai vechi apelează la client-cert-not-required, ortografia veche a aceleiași idei, așa că folosiți directiva documentată de versiunea instalată. În orice caz, schimbarea are loc pe server și niciun profil de client nu o poate executa.

Fragmentul de mai jos este întreaga schimbare pe partea serverului și, singur, nu este o configurație de autentificare funcțională. verify-client-cert none elimină cerința de certificat, în timp ce username-as-common-name face numele contului identitatea pe care o văd apelurile inverse ulterioare și fișierele fiecărui client. Niciuna dintre linii nu verifică o parolă, așa că un verificator trebuie să existe în continuare.

verify-client-cert none
username-as-common-name

Acel verificator este un plugin sau un script controlat de auth-user-pass-verify și trebuie să fie la locul lui înainte ca vreuna dintre liniile de mai sus să însemne ceva. Inversarea ordinii vă oferă o fereastră în care serverul nu cere niciun certificat și nu verifică niciun cont.

Ce verifică în continuare serverul

Renunțarea la certificatul de client nu înseamnă renunțarea la TLS. Serverul își păstrează certificatul și cheia, iar clientul păstrează încrederea în CA și verificările numelui de gazdă care îl împiedică să vorbească cu un impostor. Eliminarea remote-cert-tls server sau a pachetului CA pentru că clientul nu mai are certificat este o citire greșită comună și gravă, iar referința 2.6 spune explicit că cele două direcții sunt independente. Una dovedește serverul clientului; cealaltă dovedește clientul serverului.

Un profil poate purta și un bloc tls-auth sau tls-crypt. Aceasta este o cheie partajată a canalului de control cu propriul ciclu de distribuție și rotație, așa că un fișier fără linii de certificat sau cheie nu este automat sigur de publicat. Tratați-l ca pe un secret până când l-ați citit.

Un fișier de certificat copiat dintr-un profil funcțional nu dovedește nimic de unul singur; posesia înseamnă deținerea cheii private care îi corespunde, ceea ce verifică o implementare autentificată prin certificat. Un fișier care conține un certificat nu este un fișier cu care se poate autentifica.

Ce trebuie să facă verificatorul

Cu cerința de certificat eliminată, totul se sprijină pe verificator: un plugin sau un script controlat de auth-user-pass-verify. Trebuie să respingă acreditările invalide, să respingă conturile dezactivate sau neeligibile și să eșueze închis când nu poate ajunge la backend-ul său. username-as-common-name este adesea activat alături, iar asta schimbă identitatea pe care o văd apelurile inverse ulterioare și fișierele de configurare ale fiecărui client. Nu verifică o parolă și nu face un cont neeligibil eligibil. Acestea sunt sarcini separate, iar amestecarea lor este modul în care o migrare trece testul căii fericite și eșuează la primul său incident real.

Testați cazurile negative la fel de atent ca pe cel pozitiv. Un profil care afișează o solicitare de parolă dovedește doar că clientul poate desena o solicitare, în timp ce un server care acceptă parola greșită dovedește ceva mult mai rău. Adăugați un cont dezactivat și o acreditare expirată la setul de teste, nu doar o parolă rea.

Schimbați politica, profilul și maparea împreună

Coordonați trei lucruri: directiva serverului, profilul clientului și maparea identității pentru fiecare client. Schimbați-le separat și clienții eșuează înainte de verificare sau se conectează sub un nume la care administratorul nu se aștepta, ceea ce este mai rău pentru că pare un succes. O conexiune care reușește sub identitatea greșită este mai greu de observat decât una care eșuează.

Păstrați două conturi de test pentru această cale, unul valid și unul cunoscut ca rău, și folosiți-le pe ambele după orice schimbare a verificatorului. Contul valid dovedește calea fericită și maparea identității; cel rău dovedește că respingerea încă funcționează. Niciunul dintre teste nu vă spune nimic despre regulile de eligibilitate, așa că adăugați un cont care ar trebui refuzat din motive de politică dacă implementarea le are. Rulați toate trei după fiecare schimbare, pentru că un verificator care începe să accepte tot arată exact ca o autentificare funcțională.

Înregistrați ce metode de autentificare acceptă de fapt serverul, nu cele sugerate de profil. Acea înregistrare răspunde la întrebarea pe care oamenii o pun mereu, și anume cine se poate conecta la acest serviciu. Ea supraviețuiește și următorului administrator, care altfel ar redescoperi-o dintr-o captură de pachete.