Por que editar un ficheiro .ovpn non pode activar MFA no servidor

Engades auth-user-pass a un perfil, volves conectar e o cliente pide un nome de usuario e un contrasinal. Parece que MFA está activado. Despois escribes un código da conta equivocada, ou un código que caducou hai dez minutos, e o túnel segue levantándose. Ese é o síntoma: o cliente cambiou, o servidor non. Un contrasinal dun só uso só é un factor cando un verificador no servidor decide se é válido para a identidade que o reclama.

A solicitude só demostra que o cliente preguntou, nada máis

Un ficheiro .ovpn é un documento do lado do cliente. Pode dicirlle ao cliente que solicite credenciais, que as garde na caché ou que deixe de facelo. Non pode rexistrar un usuario, instalar un módulo PAM nin facer que o servidor esixa un segundo factor que agora non comproba.

Instalar unha aplicación de autenticación nun teléfono tampouco crea esa relación. O proxecto Google Authenticator PAM é un compoñente de verificación de OTP que pode situarse detrás de OpenVPN; non é unha forma de pegar o inicio de sesión da conta de Google a un perfil importado.

O rexistro é a parte que un perfil non pode facer

TOTP necesita material de rexistro compartido entre a aplicación de autenticación e o seu verificador. Os seis díxitos do teléfono son a saída; a semente que hai detrás é o segredo, e pertence a unha soa identidade.

Por iso o operador necesita un proceso de rexistro que vincule a semente correcta á identidade VPN correcta, ademais de unha ruta de substitución verificada para un teléfono perdido. Deixar que os usuarios suban un ficheiro co seu propio nome converte o rexistro nunha oportunidade de apropiación de conta, e cifrar a subida non o cambia.

Un deseño baseado en PAM non ten que crear unha conta Unix separada por cada usuario VPN. A documentación do módulo admite rutas alternativas para os segredos e unha conta dedicada para o acceso a ficheiros, que é unha identidade do sistema de ficheiros e non a identidade de inicio de sesión que se verifica.

O erro habitual é unha ruta de segredo fixa que remata nun só nome de usuario, copiada dun exemplo para un só usuario. Iso é unha demostración dunha identidade, non unha busca por usuario, e usala para cada solicitude non lle dá a ninguén unha aplicación de autenticación rexistrada de forma independente. Escribe o mapeo de identidades, protexe os ficheiros de sementes e mantén as comprobacións de contrasinal, certificado e conta na mesma pila de autenticación.

Le a pila PAM para ver que se esixe realmente

Unha liña como account required pam_permit.so non implementa a elixibilidade da conta nin engade un factor. Permite esa etapa de xestión de contas de PAM, que é unha afirmación sobre unha etapa e non sobre os teus usuarios.

O mesmo se aplica ás opcións de rexistro permisivas. Aceptar usuarios sen ningún segredo rexistrado pode ser unha decisión deliberada de despregamento, pero non é proba de que MFA sexa obrigatorio, e debería anotarse como unha excepción temporal con data de fin.

Axusta a interacción do cliente ao deseño do servidor

auth-user-pass

Esa directiva pide introducir nome de usuario e contrasinal. Non configura PAM, non crea un rexistro de inscrición nin lle di ao servidor que o campo de contrasinal contén un valor TOTP. A integración do servidor e o cliente teñen que acordar unha interacción que o despregamento realmente admita: un desafío, un formato de credenciais combinado e documentado, ou un fluxo específico do produto.

Non engadas un código ao contrasinal só porque o cliente mostre un único campo. Iso funciona unicamente onde o complemento do servidor espera exactamente ese formato, e falla de forma confusa en todos os demais sitios.

Mantén as sementes e o material QR fóra dos perfís compartidos e dos rexistros de diagnóstico rutineiros. Un código enviado pola canle de inicio de sesión autenticada non é o mesmo obxecto que a semente entregada durante un rexistro controlado, e mesturalos nun ticket de soporte é a forma en que se escapan os segredos.

Reconexións, tokens e a proba que o resolve

Planifica que ocorre despois do primeiro inicio de sesión correcto. Un código aceptado antes pode ter caducado ou ser rexeitado como repetición na seguinte autenticación. auth-nocache controla a retención de credenciais e non instala MFA, e reneg-sec 0 non é unha definición de compatibilidade con TOTP, por moito que apareza en fíos de foro.

Algúns despregamentos emiten tokens de autenticación tras a comprobación inicial para que as reconexións non volvan preguntar. É unha decisión de deseño coa súa propia xanela de validez e a súa propia historia de revogación, non un valor predeterminado que herdas.

Despois proba a política de admisión co cliente que a xente usa de verdade. Un usuario rexistrado co contrasinal, o certificado e o código actual correctos debería conectarse. Un código incorrecto, un usuario sen rexistro e unha conta prohibida deberían fallar cada un, e o motivo debería verse no rexistro do servidor. Ata que vexas eses rexeitamentos, tes unha solicitude, non unha política.