Qual cliente consegue concluir um login SAML no AWS Client VPN

Duas pessoas fazem a mesma pergunta sobre AWS Client VPN e SAML, e recebem respostas opostas. Uma inicia sessão a partir de um portátil Ubuntu todas as manhãs; a outra tem um telefone, um perfil transferido e um cliente que rejeita uma linha desse perfil. A diferença não é sorte nem um interruptor escondido no painel. Tudo se resume a três condições: se a plataforma é uma das que a AWS suporta para o seu próprio cliente, se a ferramenta que tem na mão consegue executar a troca federada no navegador e se o endpoint está configurado para SAML. Falhe uma das três e o início de sessão pára num ponto diferente.

Três condições decidem se o início de sessão pode terminar

A plataforma vem primeiro. A AWS distribui o seu próprio cliente Client VPN para Windows, macOS e Ubuntu em AMD64, e no final de outubro de 2026 a página de requisitos do Linux refere Ubuntu 22.04, 24.04 e 26.04. Uma compilação reembalada, um pacote convertido ou outra distribuição podem funcionar, mas não é uma plataforma suportada, e quando falha, a linha de suporte é você.

O cliente vem em segundo. O início de sessão federado não é uma opção de perfil que qualquer aplicação compatível com OpenVPN analise. O cliente fornecido abre o seu fornecedor de identidade num navegador, recebe a resposta de autenticação assinada e envia essa resposta ao endpoint. Uma aplicação que apenas lê o perfil e levanta um túnel não executa este passo, por mais limpo que pareça o seu registo de ligação.

O endpoint vem em terceiro. Um endpoint com credenciais do Active Directory ou certificados mútuos tem uma disposição completamente diferente, e trocar de cliente não a altera. Confirme o modo de autenticação com quem emitiu o perfil antes de depurar qualquer outra coisa.

Em conjunto, as três condições dão uma breve tabela de decisão:

Porque é que uma importação OpenVPN pára em auth-federate

Um perfil AWS Client VPN exportado transporta uma diretiva que diz ao cliente que a autenticação acontece fora do túnel, através de federação. Um cliente OpenVPN genérico ou rejeita a linha de imediato ou ignora-a e fica sem credenciais para oferecer. É aqui que terminam a maioria das tentativas no Android: o perfil é importado, a aplicação protesta, ou a ligação morre com um erro de configuração antes de um único pacote sair do dispositivo.

Eliminar auth-federate é o passo seguinte tentador, e transforma uma falha clara numa falha confusa. Remover uma diretiva não converte um endpoint SAML em autenticação com nome de utilizador e palavra-passe. O endpoint continua a esperar uma resposta SAML assinada e rejeita o que o cliente envia em vez disso. A palavra-passe da sua conta, o perfil transferido e uma asserção copiada não são credenciais intermutáveis.

Iniciar sessão no fornecedor de identidade no Chrome no telefone apenas prova que o fornecedor de identidade aceitou o utilizador. Não diz nada sobre se a resposta chega a um cliente capaz de a devolver ao endpoint. Os requisitos de autenticação federada tornam o cliente fornecido parte do fluxo precisamente por isso: o passo no navegador é necessário e não suficiente.

Como é o caminho suportado para o desktop Linux

Instale o pacote que a AWS publica para Ubuntu AMD64 com o gestor de pacotes do sistema e depois abra a ligação a partir desse cliente em vez de importar o perfil para uma aplicação VPN genérica. Use o perfil que o seu administrador exportou para este endpoint; não substitua nenhum URL de retorno nem nenhum identificador de cliente de um guia mais antigo, mesmo que o cliente o aceite.

Inicie a ligação, conclua o início de sessão e qualquer pedido MFA no navegador que abrir, e deixe o fluxo de retorno do navegador para o cliente terminar. Depois peça o endereço privado de que realmente precisa, de novo. Uma página que anuncia um início de sessão bem-sucedido não é prova de que o túnel subiu.

O cliente Linux reserva as portas TCP locais 8096 a 8115 para respostas SAML. Quando a passagem fica pendurada depois de o fornecedor de identidade o ter aceitado, veja o que já está à escuta nesse intervalo:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Uma porta ocupada, ou software de segurança do endpoint que bloqueia o ouvinte de loopback, produzem um início de sessão que parece concluir-se e depois nunca liga. Mantenha esse intervalo local. É um caminho de retorno do lado do cliente, não algo para abrir num grupo de segurança EC2 ou numa regra de firewall de gateway, e abri-lo à internet acrescenta exposição sem resolver nada.

Leia a etapa que falha antes de mudar qualquer coisa

Culpar o cliente é o reflexo habitual, mas cada ponto de falha pertence a um dono diferente. Descubra primeiro onde está realmente.

• Não se abre nenhuma janela do navegador. Verifique o modo de autenticação do perfil, a ligação que escolheu e a integração com o navegador predefinido do desktop.
• O fornecedor de identidade rejeita a conta. Atribuição da conta, inscrição em MFA ou configuração da aplicação SAML, tudo território do administrador.
• O navegador termina mas o cliente nunca liga. Uma resposta de autenticação expirada ou inutilizável, uma porta de retorno bloqueada ou uma passagem falhada.
• O túnel está de pé mas a aplicação está inalcançável. Rotas do endpoint, regras de autorização, grupos de segurança, DNS. Repetir o início de sessão no navegador não pode acrescentar uma permissão de rede em falta.

Guarde o texto do erro do cliente e a hora da tentativa quando escalar. A afirmação de que o SAML está avariado e a afirmação de que o cliente nunca recebeu uma resposta de autenticação válida levam as pessoas a sítios completamente diferentes.

Quando o requisito é Android mesmo assim

O Android não é uma plataforma para a qual a AWS publique o seu cliente, por isso a resposta honesta é que não há nenhum cliente móvel suportado para instalar. É uma limitação de conceção, não um quebra-cabeças para resolver no telefone editando o perfil até algo ligar.

O que pode mudar é a conceção de acesso por trás disso, e essa decisão pertence ao administrador: um caminho de acesso aplicacional aprovado para o único serviço interno de que o telefone precisa, um produto VPN com suporte móvel que a organização já opera, ou um desktop suportado para o endpoint que só usa SAML. Cada opção traz a sua própria configuração de endpoint, inscrição de identidade e regras de autorização, e o utilizador não consegue criar nenhuma delas a partir de um perfil transferido.

As ferramentas de terceiros que afirmam fechar a lacuna exigem uma revisão explícita de suporte e segurança que cubra MFA, tratamento de respostas, política de dispositivos e ritmo de atualizações. A sua existência não as torna um cliente Android fornecido pela AWS, e não deve mover material de autenticação reutilizável para um telefone para pôr uma delas a funcionar.

Dê ao administrador três factos em vez de uma longa conversa sobre diretivas: o modo de autenticação do endpoint, o recurso privado que o telefone tem de alcançar e o prazo. Isso basta para escolher entre um desktop, um caminho de acesso aplicacional e um novo produto VPN.

Verifique as condições por ordem antes de abrir outro pedido: plataforma na lista de clientes fornecidos, uma ferramenta capaz de concluir a troca no navegador, um endpoint realmente configurado para federação e, no Linux, o intervalo de portas de loopback. O primeiro elemento que falha é o que há a corrigir. Tudo o resto é conjetura.