Gateway Juniper ou Pulse: qual protocolo OpenConnect usar
O sinalizador de protocolo decide a troca de login. Compare o suporte de Network Connect e Pulse e depois ajuste o cliente ao que o gateway realmente serve.
Escolher um protocolo para o OpenConnect é um exercício de correspondência, não uma busca de marca. Um gateway que diz Juniper na página de login pode expor Network Connect, Pulse ou ambos, e o padrão do cliente não é nenhum deles. Adivinhar custa um login malsucedido e, pior, uma thread de suporte que culpa as credenciais por uma incompatibilidade de protocolo. Confirme o serviço antes de digitar um nome de host em um perfil.
O OpenConnect chama o protocolo mais antigo de nc e o mais novo de pulse, e ambos vivem no mesmo binário. O sinalizador escolhido muda a troca de login, não o roteamento após uma conexão bem-sucedida.
Os dois nomes de protocolo compartilham uma história de produto
O Network Connect da Juniper e o cliente Pulse Secure posterior são protocolos diferentes que uma família de dispositivos expôs ao longo do tempo. O OpenConnect ganhou um manipulador nc para o primeiro e um manipulador pulse para o segundo. São caminhos de código separados com formatos de requisição separados, então o suporte em um não diz nada sobre o outro.
A diferença aparece imediatamente na conversa de login: endpoints, campos do formulário e a forma como o cliente relata um segundo fator rejeitado variam entre os dois manipuladores.
Escolher na linha de comando é uma mudança de uma palavra: openconnect --protocol=nc vpn.example.com para Network Connect, ou openconnect --protocol=pulse vpn.example.com para Pulse. Ambas as tentativas são tentativas de conexão reais que podem reconfigurar rotas e DNS, então execute-as deliberadamente. Nunca coloque uma senha na linha de comando nem desative verificações de certificado para contornar um erro de protocolo, porque isso esconde a incompatibilidade em vez de corrigi-la. Se precisar ver o que o cliente envia, --dump-http-traffic imprime a troca, o que geralmente identifica o manipulador que o gateway espera.
Combine o protocolo com o que o gateway expõe
O dispositivo responde apenas ao protocolo para o qual está configurado. Um serviço somente Pulse rejeita um login nc mesmo com credenciais válidas, e um serviço antigo de Network Connect não tem endpoint pulse para responder. Pergunte ao administrador qual está habilitado e qual cliente eles suportam. Um dispositivo renomeado, uma página wiki desatualizada e um portal web familiar são todas evidências fracas.
Depois de saber o protocolo, confirme os requisitos ao redor: autenticação por certificado ou token, uma seleção de grupo de autenticação e qualquer verificação de conformidade do endpoint. Essas decidem se um cliente de linha de comando consegue concluir o login.
A autenticação pode resolver a questão antes do protocolo
Uma implantação pode exigir um certificado de cliente, uma viagem SAML pelo navegador ou um verificador de host que inspeciona a máquina antes de conceder acesso. O manipulador pulse do OpenConnect documenta limites de compatibilidade para alguns desses fluxos, e o manipulador nc tem suas próprias lacunas. Uma senha que funciona no navegador prova que a conta é válida; não prova que uma CLI ou um plugin de desktop arbitrário consiga concluir a mesma sequência. Quando há um verificador de host, o cliente precisa de um script de envolvimento fornecido pelo administrador. Sem isso, o login trava após a primeira resposta e parece uma falha de protocolo quando na verdade é uma etapa de conformidade ausente.
A seleção de grupo de autenticação é o outro ponto de tropeço comum, porque um gateway com vários grupos espera que o cliente nomeie um.
Na linha de comando, --authgroup="Employees" fornece essa escolha, e omiti-la pode deixar a sessão em um grupo padrão que rejeita a conta. Com certificados, --certificate aponta para o certificado e a chave do cliente, e o gateway ainda pode exigir um token depois. Teste a sequência completa uma vez com saída detalhada antes de automatizar qualquer coisa em volta.
Quando a interface de desktop não consegue expressar a escolha
As interfaces gráficas trazem seus próprios conjuntos de recursos, e um plugin mais antigo pode ser anterior ao protocolo de que você precisa. A integração OpenConnect do NetworkManager guarda a escolha nos dados de conexão, então nmcli connection modify "Office VPN" vpn.data "protocol=pulse" pode definir o que o editor não mostra. Verifique se a versão instalada do plugin suporta a chave antes de presumir que a edição entrou em vigor.
Se um menu só oferece PPTP ou L2TP, escolher um deles não converte um serviço Pulse nesse protocolo. Instale a integração aprovada em vez de mudar para o que o menu por acaso lista.
O que registrar quando o login ainda falha
Registre quatro coisas: o protocolo selecionado, as versões do cliente e do plugin, o fluxo de autenticação esperado e o primeiro erro que voltou com um código de status em vez de um tempo limite. Esse conjunto separa um manipulador errado de um certificado ausente, um grupo de autenticação rejeitado ou uma verificação de conformidade bloqueada. A saída detalhada vale a pena ser guardada pelo mesmo motivo, porque mostra a requisição que falhou e não apenas o sintoma.
Guarde o comando ou o perfil que funciona ao lado do nome do gateway quando der certo. Caso contrário, a próxima pessoa que se conectar repetirá a mesma suposição de marca contra protocolo.