Script auth-user-pass-verify d’OpenVPN: encerta el codi de sortida

OpenVPN actua sobre exactament una sortida d’un script d’inici de sessió: l’estat de sortida. La resta del que fa el script és decoració. Un ganxo pot arribar al verificador correcte, analitzar la resposta i imprimir una línia amable mentre retorna un estat que significa el contrari del que el seu autor pretenia. Llegeix primer el contracte i escriu l’adaptador al seu voltant, i tota aquesta classe d’errors desapareix.

El contracte és petit: identifica el compte que s’ha enviat, pregunta al verificador aprovat la qüestió prevista i accepta només el resultat positiu documentat d’aquest verificador per a aquesta sol·licitud. La resta és plomeria.

Els tres estats que el ganxo pot retornar

Per a auth-user-pass-verify, el manual d’OpenVPN 2.6 defineix el codi de sortida 0 com a acceptació, l’1 com a rebuig i el 2 com a autenticació ajornada. Aquestes són les úniques tres respostes que entén el servidor, i cadascuna té una conseqüència diferent per a la connexió. Un script que surt amb l’estat de la seva última ordre ha deixat, de fet, que una crida de registre o un pas de neteja voti. Escriu l’estat explícitament a cada branca, incloses les branques que mai no van arribar al verificador.

L’èxit HTTP i l’èxit d’autenticació són capes separades, i confondre’ls és la manera més habitual que aquest ganxo falli. Una resposta 202 vol dir que la sol·licitud s’ha acceptat per processar, no que s’hagi verificat una contrasenya. Defineix l’estat esperat, la forma de la resposta i el veredicte final a partir del contracte de l’API que t’han donat, i no inventis un nom de camp perquè sembli plausible.

Si la resposta arriba de veritat més tard, aquest és el camí ajornat i s’ha de construir com a tal. Un intent ajornat que no es completa mai reté recursos fins que expira el temps d’espera.

Llegeix el fitxer de credencials exactament tal com està escrit

Amb el mètode documentat via fitxer, el servidor escriu el nom d’usuari i la contrasenya com a dues primeres línies d’un fitxer temporal, passa aquest camí al script i elimina el fitxer quan el script retorna. Llegeix aquestes dues línies com a dades: no facis mai source del fitxer, no l’avaluïs mai i no enganxis mai el seu contingut en una línia d’ordres on la taula de processos el pugui veure. Conserva la contrasenya byte a byte, perquè normalitzar-la com normalitzaries un nom d’usuari canvia la credencial en silenci. El directori utilitzat per a aquest fitxer temporal és una decisió de desplegament, així que confirma que existeix i que no és llegible per tothom a l’amfitrió.

Mantingues la credencial pròpia del verificador separada de la de l’usuari: pertany a la integració de la passarel·la, viu a la botiga de secrets de la plataforma i només necessita el permís de verificar, així que no és prova que cap persona concreta s’hagi autenticat. Tampoc no deixis que el ganxo es converteixi en un segon verificador de contrasenyes. Reimplementar a mà una comparació de hash no es fa segur optimitzant el bucle, i un verificador mantingut ja entén l’esquema amb sal i cost del magatzem de comptes.

Decideix què significa una resposta no classificable

Els temps d’espera, els errors de transport, les respostes mal formades i un backend no disponible comparteixen una propietat: cap d’ells no és una verificació positiva. El ganxo hauria de fallar tancat per a cadascun i enregistrar un motiu sobre el qual un operador pugui actuar. Aquest motiu pertany a un registre protegit, no a un missatge retornat a la persona que intenta connectar-se.

Sigues igual de curós amb els camins que no arriben mai al verificador. Un valor de configuració absent, un secret il·legible o una dependència no instal·lada haurien de produir un rebuig amb un marcador operatiu distint en lloc d’una acceptació accidental. Prova aquestes branques eliminant la dependència en un laboratori en comptes de raonar sobre elles. On un fall de registre pot canviar l’estat de sortida, el registre s’ha convertit en part de la decisió i cal fer-lo inofensiu.

La configuració del servidor també hi té a veure: els scripts definits per l’usuari només es respecten quan la configuració en curs els permet al nivell de seguretat requerit, i aquest paràmetre és una tria deliberada, no un valor per defecte que calgui apujar.

Verifica el veredicte, no la línia impresa

Construeix una prova que inspeccioni directament l’estat de sortida. Escriu un fitxer de credencials de mostra, executa el ganxo contra ell amb un compte bo conegut i un de dolent conegut, i llegeix l’estat que informa l’intèrpret d’ordres en lloc del text que imprimeix el script. Aquesta única comprovació atrapa la majoria d’errors de contracte abans que cap client es connecti.

Després passa els mateixos casos per un client real contra un oient que no sigui de producció i confirma què ha enregistrat el servidor: acceptat, rebutjat o ajornat. Cobreix un compte desactivat, una contrasenya incorrecta, una resposta mal formada del verificador, un temps d’espera i un verificador inabastable. Si algun cas acaba en un estat que no pots anomenar, l’adaptador no està acabat.

Mantingues el mapatge del resultat del verificador a l’estat de sortida al costat del script al repositori, perquè el següent enginyer pugui llegir el contracte sense fer enginyeria inversa del codi.