O login VPN trava após um Access-Challenge do RADIUS

A senha está correta, o login VPN falha mesmo assim, e o servidor RADIUS pode ter feito exatamente o que lhe foi ordenado. O gateway provavelmente recebeu um Access-Challenge, não mostrou nada útil e então expirou ou tratou essa resposta como rejeição. Do lado do cliente parece credencial errada ou túnel quebrado. A causa costuma estar no meio de uma conversa que ninguém capturou.

Um login, duas trocas RADIUS

Quando o backend quer um segundo fator, ele não responde à primeira solicitação com aceitação ou rejeição. Responde com o código 11 e espera a próxima resposta do usuário, que o gateway precisa enviar de volta numa solicitação de acompanhamento. Esse acompanhamento pertence à mesma conversa de autenticação, não a uma nova tentativa de login.

Numa configuração que funciona, o usuário vê um segundo prompt: primeiro a senha, depois um código de uso único, ou um único prompt combinado se o operador documentou um. Numa configuração quebrada, o segundo prompt nunca aparece e o login simplesmente falha.

Esse é o sintoma a perseguir, e é fácil de confirmar apenas do lado do cliente: se o cliente VPN pede exatamente um segredo e depois rejeita uma senha que você sabe válida, a troca provavelmente terminou no desafio.

O que o desafio realmente carrega

A especificação do RADIUS descreve o código 11 na seção 4.4 e permite dois atributos que importam aqui. Reply-Message contém texto destinado ao usuário, e State contém um valor opaco que o servidor quer de volta. O NAS não deve interpretar State, apenas devolvê-lo sem alteração.

A solicitação de acompanhamento usa um novo Identifier e um novo Request Authenticator, e precisa carregar o mesmo valor de State mais a resposta do usuário. O servidor a associa ao desafio pendente por meio desse State, e por isso um gateway que regenera ou descarta o atributo não consegue completar a cerimônia. O response authenticator de cada resposta também precisa validar, senão o NAS deve descartar o pacote.

A seção 4.4 acrescenta o detalhe que explica a maioria das falhas silenciosas: um NAS que não suporta desafios trata Access-Challenge como rejeição. Se o serviço de VPN do seu gateway é anterior a esse suporte ou o omite, a solicitação do backend por um segundo fator vira um «falha de autenticação» imediato sem nenhum prompt.

Onde a solicitação encadeada se perde

O primeiro suspeito é o caminho do prompt, não a credencial. Um portal que mostra um campo OTP para logins web não faz o mesmo automaticamente para o serviço de VPN, e alguns gateways só passam um desafio a clientes que anunciam a capacidade. Teste a mesma conta nos dois pontos de entrada; se o portal funciona e a VPN não, você está olhando a entrega, não o token.

O formato de entrada é o segundo suspeito. Concatenar senha e código sem o separador documentado pelo fornecedor, ou deixar uma credencial salva reproduzir um código antigo, falha de um jeito que parece idêntico a uma senha errada. Use o prompt separado ou o formato combinado documentado pelo operador, e nunca improvise um delimitador.

Defeitos específicos de versão existem, mas uma lista de versões corrigidas de anos atrás não é um diagnóstico para a implantação de hoje. Leia as notas de versão do software que você realmente executa e mantenha o estágio de troca observado como sua evidência.

Rastreie uma única tentativa de ponta a ponta

Reproduza uma vez, com a depuração do lado do servidor ativada, e mantenha qualquer outra sessão fora da janela de captura:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Na saída, procure a forma da conversa em vez de uma única linha. Um primeiro Access-Request com Identifier 3, um Access-Challenge que carrega State, e então um segundo Access-Request com Identifier 4 que repete esse State e inclui a resposta do usuário. Se a segunda solicitação faltar, o gateway nunca fez o acompanhamento. Se ela chegar sem State, o servidor não consegue associá-la ao desafio pendente e normalmente vai rejeitar.

Oculte credenciais, tokens e dados de identidade desnecessários ao compartilhar o rastreamento, e correlacione eventos de uma única tentativa em vez de misturar repetições de várias abas do navegador. Os carimbos de tempo são seus amigos aqui; um desafio que chega depois de o cliente desistir parece rejeição para o usuário e resposta lenta no log.

O estado final que você quer é uma conversa concluída e autorizada, seguida do acesso pretendido ao serviço. Uma resposta que chega do servidor RADIUS prova muito menos do que isso.