Por que editar um ficheiro .ovpn não pode ativar o MFA no servidor

Você adiciona auth-user-pass a um perfil, volta a ligar-se e o cliente pede um nome de utilizador e uma palavra-passe. Parece que o MFA está ativo. Depois introduz um código da conta errada, ou um código que expirou há dez minutos, e o túnel continua a subir. Esse é o sintoma: o cliente mudou, o servidor não. Uma palavra-passe de uso único só é um fator quando um verificador no servidor decide se é válida para a identidade que a reivindica.

O pedido só prova que o cliente perguntou, nada mais

Um ficheiro .ovpn é um documento do lado do cliente. Pode dizer ao cliente para pedir credenciais, guardá-las em cache ou deixar de o fazer. Não pode registar um utilizador, instalar um módulo PAM nem fazer o servidor exigir um segundo fator que atualmente não verifica.

Instalar uma aplicação de autenticação num telemóvel também não cria essa relação. O projeto Google Authenticator PAM é um componente de verificação OTP que pode ficar atrás do OpenVPN; não é uma forma de colar o início de sessão da conta Google a um perfil importado.

O registo é a parte que um perfil não consegue fazer

O TOTP precisa de material de registo partilhado entre a aplicação de autenticação e o seu verificador. Os seis dígitos no telemóvel são a saída; a semente por trás deles é o segredo, e pertence a uma única identidade.

Por isso, o operador precisa de um processo de registo que ligue a semente certa à identidade VPN certa, além de um caminho de substituição verificado para um telemóvel perdido. Deixar os utilizadores carregarem um ficheiro com o seu próprio nome transforma o registo numa oportunidade de apropriação da conta, e cifrar o carregamento não muda isso.

Um desenho baseado em PAM não tem de criar uma conta Unix separada por cada utilizador VPN. A documentação do módulo suporta caminhos alternativos para os segredos e uma conta dedicada para o acesso a ficheiros, que é uma identidade do sistema de ficheiros e não a identidade de início de sessão que está a ser verificada.

O erro comum é um caminho de segredo fixo que termina num único nome de utilizador, copiado de um exemplo para um só utilizador. Isso é uma demonstração de uma identidade, não uma pesquisa por utilizador, e usá-lo em cada pedido não dá a ninguém uma aplicação de autenticação registada de forma independente. Escreva o mapeamento de identidades, proteja os ficheiros de sementes e mantenha as verificações de palavra-passe, certificado e conta na mesma pilha de autenticação.

Leia a pilha PAM para ver o que é realmente exigido

Uma linha como account required pam_permit.so não implementa a elegibilidade da conta e não acrescenta um fator. Permite essa fase de gestão de contas do PAM, o que é uma afirmação sobre uma fase e não sobre os seus utilizadores.

O mesmo se aplica às opções de registo permissivas. Aceitar utilizadores sem qualquer segredo registado pode ser uma decisão deliberada de implementação, mas não é prova de que o MFA seja obrigatório, e deve ser registada como uma exceção temporária com data de fim.

Alinhe a interação do cliente com o desenho do servidor

auth-user-pass

Essa diretiva pede a introdução de nome de utilizador e palavra-passe. Não configura o PAM, não cria um registo de inscrição e não diz ao servidor que o campo da palavra-passe contém um valor TOTP. A integração do servidor e o cliente têm de acordar uma interação que a implementação realmente suporte: um desafio, um formato de credenciais combinado e documentado, ou um fluxo específico do produto.

Não acrescente um código à palavra-passe só porque o cliente mostra um único campo. Isso funciona apenas onde o plugin do servidor espera exatamente esse formato, e falha de forma confusa em todos os outros sítios.

Mantenha as sementes e o material QR fora dos perfis partilhados e dos registos de diagnóstico de rotina. Um código submetido pelo canal de início de sessão autenticado não é o mesmo objeto que a semente fornecida durante um registo controlado, e misturá-los num pedido de apoio é a forma como os segredos escapam.

Reconexões, tokens e o teste que resolve a questão

Planeie o que acontece após o primeiro início de sessão bem-sucedido. Um código aceite anteriormente pode ter expirado ou ser rejeitado como repetição na autenticação seguinte. auth-nocache controla a retenção de credenciais e não instala MFA, e reneg-sec 0 não é uma definição de suporte a TOTP, por muitas vezes que apareça em tópicos de fórum.

Algumas implementações emitem tokens de autenticação após a verificação inicial, para que as reconexões não voltem a pedir. É uma decisão de desenho com a sua própria janela de validade e a sua própria história de revogação, não um valor predefinido que herda.

Depois teste a política de admissão com o cliente que as pessoas realmente usam. Um utilizador registado com a palavra-passe, o certificado e o código atual corretos deve conseguir ligar-se. Um código errado, um utilizador sem registo e uma conta proibida devem falhar cada um, e o motivo deve ser visível no registo do servidor. Enquanto não tiver visto essas recusas, tem um pedido, não uma política.