Por que o login do openfortivpn falha ao colar a URL do portal

A falha parece um problema de credenciais: o openfortivpn pede a senha, envia-a, e o gateway responde com uma rejeição ou com um redirecionamento de volta à página de login. Os usuários então digitam a senha novamente, tentam o nome de conta qualificado pelo domínio e acabam colando a URL do portal do navegador no campo de host. É esse último movimento que transforma um pequeno erro de configuração num erro confuso.

Um endereço de portal Fortinet como https://vpn.example.com/ext carrega várias peças de informação ao mesmo tempo, e apenas algumas pertencem ao cliente VPN.

O endpoint e o realm são entradas separadas

O openfortivpn espera um endpoint na forma host ou host:port, além de uma conta e, quando a implantação usa uma, um valor de realm. O realm diz ao gateway qual política de autenticação aplicar antes de avaliar a conta. É um campo separado, não um sufixo que o cliente extrai de uma URL.

Para uma implantação cujo operador confirma que o realm é ext, uma chamada não secreta tem este aspecto: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Os mesmos valores vão no arquivo de configuração como entradas host, port, username e realm. Deixe a senha fora das duas formas e deixe o cliente pedi-la, para que não acabe no histórico do shell nem num arquivo legível por todos. Uma segunda tentativa enquanto o primeiro cliente ainda mantém o túnel falhará por um motivo que nada tem a ver com o realm.

O manual do openfortivpn lista ambas as opções, então a grafia exata é fácil de confirmar antes de ligar para o suporte. Não pode, porém, dizer qual realm está configurado no seu gateway.

Um segmento de caminho não é automaticamente um realm

As URLs de portal reúnem todo tipo de coisas depois do nome do host: uma aplicação de login, um seletor de idioma, um destino de redirecionamento, um identificador de sessão. Cortar o último segmento do caminho e chamá-lo de realm funciona com frequência suficiente para ser perigoso. Pergunte ao operador qual é o valor configurado ou leia-o no perfil que a sua organização distribui.

Um realm também não é a mesma coisa que um sufixo de domínio no nome de usuário ou que a região onde o gateway está. Algumas implantações querem alice, outras querem alice@corp, e o realm decide qual delas o gateway aceitará. Mudar o formato da conta para compensar um realm errado costuma produzir uma segunda rejeição, menos informativa.

Não corrija um erro de realm mudando o host

Trocar o nome do host por um endereço IP parece remover uma camada, e quebra mais do que conserta. A validação do nome TLS compara o certificado com o nome usado pelo cliente, e um endereço IP raramente aparece nos nomes alternativos do sujeito de um certificado. A indicação do nome do servidor muda com o endereço, então um gateway que hospeda vários portais num endereço pode responder com o errado. Mantenha o nome do host e a configuração de confiança intactos enquanto corrige o parâmetro de autenticação.

Se o certificado não é confiável no seu ambiente, conserte o repositório de confiança ou fixe deliberadamente o certificado esperado. Desativar a verificação para contornar um erro de realm troca um problema de login por um risco de interceptação silenciosa.

Separe um login rejeitado de um túnel com falha

Falhas de autenticação e falhas de túnel chegam em momentos diferentes, e as mensagens são diferentes. Um erro de resolução de nome ocorre antes de qualquer handshake TLS. Uma rejeição TLS ocorre antes de as credenciais serem enviadas. Uma rejeição de realm ou de conta volta como uma resposta ao nível de HTTP do portal. Só depois dessas etapas começa a negociação PPP, e só então aparecem problemas de roteamento e DNS.

Um realm correto não cria uma rota ausente nem faz um método de login não suportado funcionar. Se o portal insiste num fluxo baseado no navegador, use o caminho suportado pelo cliente para esse fluxo em vez de repetir uma troca de senha e esperar que a sessão corresponda.

Guarde os valores onde o próximo início os encontrará

Assim que uma conexão funcionar, escreva o gateway, a porta, a conta e o realm no perfil gerenciado em vez de num alias do shell. Perfis guardados num repositório ou num sistema de gestão de configuração impedem que o próximo início apanhe em silêncio o realm de outro perfil.

Teste novamente uma conexão de ponta a ponta e confirme tanto a política aplicada quanto o acesso a um recurso de que realmente precisa. O sucesso da autenticação é o começo dessa verificação, não o fim.