O início de sessão do OpenConnect cai na página errada? Verifique primeiro o caminho

Colas o endereço do e-mail de integração, o cliente chega à gateway e o formulário de início de sessão que aparece é o portal geral e não o do parceiro que o operador descreveu. Nada dá erro, e é exatamente isso que confunde: o túnel pode até subir, só que atrás do ponto de entrada errado. O caminho desse URL fazia trabalho, e o que quer que o tenha substituído perdeu esse trabalho.

Separa duas coisas que chegam como uma única cadeia num ticket: o endereço que chega ao serviço e a entrada que decide onde começa a autenticação. Reparar a primeira ignorando a segunda é como um nome de anfitrião correto continua a produzir o início de sessão errado.

O que o cliente envia antes de veres um formulário

Com um endereço como https://vpn.example.net/partners, o primeiro ato do cliente é um pedido HTTPS a esse caminho e não ao anfitrião nu. O que volta é normalmente um redirecionamento para o ponto de início de sessão, ou o próprio formulário. Um cliente que só recebe vpn.example.net começa na página de destino predefinida que houver, e isso pode ser outro portal, outra lista de grupos ou uma página que espera um protocolo completamente diferente. A diferença vê-se nos cabeçalhos de resposta muito antes de se escrever qualquer credencial.

Por isso um separador do navegador que funciona e um perfil de cliente que falha podem nomear a mesma gateway e mesmo assim discordar. O navegador seguiu o caminho; o perfil nunca o teve.

Duas entradas que parecem intercambiáveis e não são

O OpenConnect expõe o caminho HTTPS inicial como --usergroup, e a página do manual trata um URL completo que transporte esse caminho como o mesmo pedido escrito de outra forma. --authgroup é uma opção separada: escolhe uma entrada da lista que a gateway apresenta dentro do formulário de início de sessão. Alguns protocolos chamam a essa entrada grupo, outros domínio ou gateway, e é exatamente aí que os dois parâmetros se confundem.

Um serviço pode legitimamente precisar dos dois. O caminho pode levar-te ao portal correto enquanto o formulário ainda pede que escolhas entre grupos dentro dele. Dar o nome do portal como nome do grupo, ou o contrário, produz um início de sessão que parece aceite e depois não autoriza, porque o valor era sintaticamente válido e semanticamente errado.

Pede ao operador cada valor na sua própria linha: caminho de entrada, seleção no formulário e se ambos são necessários. Não deduzas um do outro só porque os rótulos soam parecidos.

Porque é que cortar o caminho muda o resultado

Os clientes que só aceitam anfitrião e porta muitas vezes ligam-se na mesma, por isso o sintoma raramente é uma falha dura. Em vez disso ficas com a página de início de sessão errada, uma lista de grupos vazia, um nome de certificado que já não corresponde ao que o operador publicou, ou um túnel que sobe sem rota para o serviço que querias. Cada um destes fica numa camada diferente, e nenhum se repara colando uma cadeia mais longa num campo documentado como nome de anfitrião. Dois deles também são indistinguíveis do exterior, porque ambos chegam como um formulário de início de sessão que simplesmente não continua.

Substituir o nome do anfitrião por um endereço IP é um erro separado que muitas vezes viaja com este. A seleção de serviço baseada no nome e a validação do certificado dependem ambas do nome, por isso um endereço numérico pode transformar um problema de formato de caminho num erro TLS.

Os endereços do navegador transportam também mais do que caminhos. Os identificadores de sessão, os destinos de redirecionamento, os prefixos de idioma e os parâmetros temporários de início de sessão aparecem todos na barra de endereços, e nenhum deles pertence a um perfil de cliente guardado.

Confirma o ponto de entrada antes de editar qualquer outra coisa

Lê os cabeçalhos do caminho que te deram. Um pedido como curl -sS -o /dev/null -D - https://vpn.example.net/partners imprime a linha de estado e qualquer cabeçalho Location sem seguir o redirecionamento. Um 302 que aponta para um ponto de início de sessão com nome confirma que o caminho existe e mostra para onde vai; um 404 significa que o endereço do operador está desatualizado.

Depois reproduz o mesmo ponto de entrada no cliente aprovado, por exemplo openconnect --usergroup=partners vpn.example.net, e observa que formulário aparece. Se o formulário estiver correto e o túnel continuar a falhar, o caminho nunca foi o problema e a próxima paragem é a política ou o encaminhamento.

Regista o nome do anfitrião, a porta, o protocolo, o caminho de entrada e a seleção no formulário como cinco campos separados no ticket. É essa lista que permite ao engenheiro seguinte distinguir um servidor inalcançável de uma recusa TLS, de uma seleção recusada e de um túnel que subiu sem as rotas de que precisava.