OpenVPN sense certificat de client: política del servidor, no perfil

Suprimiu les línies de certificat i clau, lliureu el perfil i la connexió continua fallant amb un error de certificat. El perfil mai no era allò que imposava aquest requisit. El servidor decideix si el certificat de client és obligatori, i cap edició al costat del client no ho negocia. Per tant, la solució és un canvi de política del servidor, fet deliberadament, amb tot el que en depèn actualitzat en la mateixa passada.

El perfil no és la política

Community OpenVPN 2.6 arriba amb els certificats de client obligatoris, perquè verify-client-cert per defecte és require. Posar-lo a none és el que atura l'exigència d'un certificat i lliura l'autenticació del client a qualsevol disposició d'usuari i contrasenya que el servidor ja faci servir. Les guies antigues recorren a client-cert-not-required, l'ortografia heretada de la mateixa idea, així que feu servir la directiva que documenta la versió instal·lada. En qualsevol cas, el canvi es fa al servidor i cap perfil de client no el pot executar.

El fragment següent és tot el canvi al costat del servidor, i per si sol no és una configuració d'autenticació funcional. verify-client-cert none elimina el requisit de certificat, mentre que username-as-common-name fa que el nom del compte sigui la identitat que veuen les devolucions de trucada posteriors i els fitxers de cada client. Cap de les dues línies no comprova una contrasenya, així que encara ha d'existir un verificador.

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

Aquest verificador és un connector o un script impulsat per auth-user-pass-verify, i ha d'estar al seu lloc abans que qualsevol de les línies anteriors signifiqui res. Invertir l'ordre us dona una finestra en què el servidor no demana cap certificat i no comprova cap compte.

Què encara verifica el servidor

Deixar el certificat de client no vol dir deixar TLS. El servidor conserva el seu certificat i la seva clau, i el client conserva la confiança en la CA i les comprovacions de nom d'amfitrió que li impedeixen parlar amb un impostor. Treure remote-cert-tls server o el paquet de CA perquè el client ja no té certificat és una mala lectura comuna i greu, i la referència de la 2.6 diu explícitament que les dues direccions són independents. Una demostra el servidor al client; l'altra demostra el client al servidor.

Un perfil també pot portar un bloc tls-auth o tls-crypt. És una clau compartida del canal de control amb el seu propi cicle de distribució i rotació, així que un fitxer sense línies de certificat ni clau no és automàticament segur de publicar. Tracteu-lo com un secret fins que l'hàgiu llegit.

Un fitxer de certificat copiat d'un perfil funcional no demostra res per si sol; la possessió vol dir tenir la clau privada que hi coincideix, cosa que comprova un desplegament autenticat per certificat. Un fitxer que conté un certificat no és un fitxer amb què es pugui autenticar.

Què ha de fer el verificador

Amb el requisit de certificat eliminat, tot descansa en el verificador: un connector o un script impulsat per auth-user-pass-verify. Ha de rebutjar credencials no vàlides, rebutjar comptes desactivats o no elegibles i fallar tancat quan no pot arribar al seu backend. username-as-common-name sovint s'activa al costat, i canvia la identitat que veuen les devolucions de trucada posteriors i els fitxers de configuració de cada client. No verifica una contrasenya ni fa elegible un compte que no ho és. Són feines separades, i barrejar-les és com una migració passa la prova del camí feliç i falla en el seu primer incident real.

Proveu els casos negatius amb tanta cura com el positiu. Un perfil que mostra una petició de contrasenya només demostra que el client pot dibuixar una petició, mentre que un servidor que accepta la contrasenya incorrecta demostra una cosa molt pitjor. Afegiu un compte desactivat i una credencial caducada al conjunt de proves, no només una contrasenya dolenta.

Canvieu la política, el perfil i el mapatge alhora

Coordineu tres coses: la directiva del servidor, el perfil del client i el mapatge d'identitat per client. Canvieu-les per separat i els clients fallen abans de la verificació, o es connecten amb un nom que l'administrador no esperava, cosa que és pitjor perquè sembla un èxit. Una connexió que té èxit amb la identitat equivocada és més difícil de notar que una que falla.

Manteniu dos comptes de prova per a aquest camí, un de vàlid i un de conegut com a dolent, i feu servir tots dos després de qualsevol canvi al verificador. El compte vàlid demostra el camí feliç i el mapatge d'identitat; el dolent demostra que el rebuig encara funciona. Cap de les dues proves no diu res sobre les regles d'elegibilitat, així que afegiu un compte que s'hagi de refusar per motius de política si el desplegament en té. Executeu les tres proves després de cada canvi, perquè un verificador que comença a acceptar-ho tot sembla exactament un inici de sessió funcional.

Enregistreu quins mètodes d'autenticació accepta realment el servidor, no els que suggereix el perfil. Aquest registre respon la pregunta que la gent continua fent, que és qui es pot connectar a aquest servei. També sobreviu al següent administrador, que si no la tornaria a descobrir a partir d'una captura de paquets.