Script auth-user-pass-verify de OpenVPN: o código de saída correcto

OpenVPN actúa sobre exactamente unha saída dun script de inicio de sesión: o estado de saída. Todo o demais que fai o script é decoración. Un hook pode chegar ao verificador correcto, analizar a resposta e imprimir unha liña amable mentres devolve un estado que significa o contrario do que pretendía o seu autor. Lea primeiro o contrato e escriba o adaptador ao seu redor, e toda esa clase de erros desaparece.

O contrato é pequeno: identifique a conta que se enviou, faga ao verificador aprobado a pregunta prevista e acepte só o resultado positivo documentado dese verificador para esa solicitude. Todo o demais é infraestrutura.

Os tres estados que o hook pode devolver

Para auth-user-pass-verify, o manual de OpenVPN 2.6 define o código de saída 0 como aceptación, 1 como rexeitamento e 2 como autenticación diferida. Esas son as únicas tres respostas que entende o servidor, e cada unha ten unha consecuencia distinta para a conexión. Un script que sae co estado do seu último comando deixou, na práctica, que unha chamada de rexistro ou un paso de limpeza vote. Escriba o estado explicitamente en cada rama, incluídas as ramas que nunca chegaron ao verificador.

O éxito HTTP e o éxito de autenticación son capas separadas, e confundilos é a forma máis habitual de que este hook falle. Unha resposta 202 significa que a solicitude se aceptou para procesamento, non que se verificase un contrasinal. Defina o estado esperado, a forma da resposta e o veredicto final a partir do contrato de API que lle deron, e non invente un nome de campo porque pareza plausible.

Se a resposta chega de verdade máis tarde, esa é a ruta diferida e hai que construíla como tal. Un intento diferido que nunca se completa retén recursos ata que caduca o tempo de espera.

Lea o ficheiro de credenciais exactamente como está escrito

Co método documentado vía ficheiro, o servidor escribe o nome de usuario e o contrasinal como as dúas primeiras liñas dun ficheiro temporal, pasa esa ruta ao script e elimina o ficheiro cando o script regresa. Lea esas dúas liñas como datos: nunca faga source do ficheiro, nunca o avalíe e nunca pegue o seu contido nunha liña de comandos onde a táboa de procesos poida velo. Conserve o contrasinal byte a byte, porque normalizalo como normalizaría un nome de usuario cambia a credencial en silencio. O directorio usado para ese ficheiro temporal é unha decisión de despregamento, así que confirme que existe e que non é lexible por todos no servidor.

Manteña a credencial propia do verificador separada da do usuario: pertence á integración da pasarela, vive no almacén de segredos da plataforma e só necesita o permiso de verificar, así que non é proba de que se autenticase unha persoa concreta. Tampouco deixe que o hook se converta nun segundo verificador de contrasinais. Reimplementar a man unha comparación de hash non se volve seguro optimizando o bucle, e un verificador mantido xa entende o esquema con sal e custo do almacén de contas.

Decida que significa unha resposta non clasificable

Os tempos de espera, os erros de transporte, as respostas mal formadas e un backend non dispoñible comparten unha propiedade: ningún deles é unha verificación positiva. O hook debería fallar pechado ante cada un deles e rexistrar un motivo sobre o que un operador poida actuar. Ese motivo pertence a un rexistro protexido, non a unha mensaxe devolta á persoa que intenta conectarse.

Sexa igual de coidadoso coas rutas que nunca chegan ao verificador. Un valor de configuración ausente, un segredo ilexible ou unha dependencia non instalada deberían producir un rexeitamento cun marcador operativo distinto en lugar dunha aceptación accidental. Probe esas ramas eliminando a dependencia nun laboratorio en vez de razoar sobre elas. Onde un fallo de rexistro pode cambiar o estado de saída, o rexistro converteuse en parte da decisión e hai que facelo inofensivo.

A configuración do servidor tamén importa aquí: os scripts definidos polo usuario só se respectan cando a configuración en execución os permite no nivel de seguridade requirido, e ese axuste é unha elección deliberada, non un valor predeterminado que haxa que subir.

Verifique o veredicto, non a liña impresa

Construa unha proba que inspeccione directamente o estado de saída. Escriba un ficheiro de credenciais de mostra, execute o hook contra el cunha conta boa coñecida e unha mala coñecida, e lea o estado que informa o intérprete de comandos en lugar do texto que imprime o script. Esa única comprobación atrapa a maioría dos erros de contrato antes de que un cliente chegue a conectarse.

Despois pase os mesmos casos por un cliente real contra un escoitador que non sexa de produción e confirme que rexistrou o servidor: aceptado, rexeitado ou diferido. Cubra unha conta desactivada, un contrasinal incorrecto, unha resposta mal formada do verificador, un tempo de espera e un verificador inalcanzable. Se algún caso acaba nun estado que non pode nomear, o adaptador non está rematado.

Manteña a correspondencia entre o resultado do verificador e o estado de saída xunto ao script no repositorio, para que o seguinte enxeñeiro poida ler o contrato sen facer enxeñaría inversa do código.