VPN do Windows versus Cisco Secure Client: qual é a certa?
Uma marca não nomeia um protocolo: o Windows oferece vários tipos nativos e o cliente da Cisco carrega perfis para mais de um modo. Leia o perfil.
Para o mesmo gateway chegam duas instruções: conecte-se com a VPN do Windows ou instale o cliente da Cisco. Nenhuma das duas nomeia a troca que o gateway espera, porque o Windows expõe vários tipos de conexão nativos e o cliente do fornecedor carrega perfis para mais de um modo. Ambos os rótulos descrevem software, enquanto o gateway negocia protocolo, autenticação e política. A resposta está no perfil, e pode ser lida sem conectar.
O rótulo nomeia software, não uma troca
Uma marca e um sistema operacional são dois fatos diferentes, e nenhum dos dois escolhe um formato de fio. O Windows inclui um conjunto de tipos nativos, e o cliente da Cisco inclui um motor de perfis que consegue conduzir SSL ou IPsec/IKEv2. Confundir os dois produz tabelas que comparam empresas em vez de comparar trocas.
A tabela abaixo substitui a pergunta sobre o produto por três locais de leitura e o campo que cada um guarda. Anote esses campos, e a ambiguidade desaparece:
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
A referência da Microsoft sobre os tipos de VPN do Windows lista IKEv2 e SSTP entre os tipos nativos, o que afasta a ideia de que um perfil nativo significa PPTP. A documentação de perfis da Cisco descreve tanto o modo SSL como o IPsec/IKEv2, com a política correspondente do concentrador. Cada fornecedor oferece várias opções, então nenhum nome identifica um único protocolo.
O que os tipos nativos colocam no fio
O IKEv2 negocia associações de segurança sobre UDP e transporta tráfego dentro do IPsec, o que o torna um par de outras implementações de IKEv2 e não um desenho específico da Microsoft. O SSTP envolve o PPP dentro de uma sessão HTTPS, então atravessa proxies que o IKEv2 não consegue e no fio parece TLS sem ser um protocolo VPN de TLS. Esses dois fatos explicam a maior parte de um chamado que relata o túnel funcionando em uma rede e falhando em outra.
L2TP com IPsec e a entrada mais antiga PPTP estão no mesmo menu suspenso, e a presença delas ali não diz nada sobre o suporte do servidor. Um menu suspenso é uma lista do que o sistema operacional pode tentar, não uma declaração de capacidade do gateway. Lê-lo como uma lista de suporte é como começa uma caça de duas horas por credenciais.
Os campos que importam em um perfil nativo são o tipo de conexão, o método de autenticação e a identidade do servidor. O tipo errado falha em um estágio diferente de uma senha ruim, e essa diferença é a pista que vale a pena seguir.
O que um cliente de fornecedor acrescenta: perfis, não um protocolo
O cliente da Cisco é um contêiner de perfis. Um modo SSL e um modo IPsec/IKEv2 diferem em troca, expectativas de porta e texto de erro, e o perfil importado escolhe entre eles. Instalar o cliente, portanto, não prova nada sobre a acessibilidade.
As versões são emparelhadas por um motivo. Recursos, fluxos de autenticação e verificações de postura são negociados entre cliente e concentrador, então um cliente antigo contra um concentrador novo pode falhar de um modo que se lê como falha de rede. Esse emparelhamento pertence à definição de conexão, não a uma nota de atualização.
Um perfil exportado de outra organização raramente combina com o concentrador local, e importá-lo pode deixar o cliente oferecendo um modo que o gateway não atende. Leia primeiro o modo do perfil e depois compare-o com o protocolo e a política de autenticação configurados no gateway. Só quando eles coincidem a rede se torna suspeita. Essa ordem poupa uma captura de pacotes que teria mostrado uma sessão TLS saudável apontada para o serviço errado.
Leia o perfil local antes de mudar qualquer coisa
No Windows a configuração nativa pode ser lida sem discar, e a saída nomeia o tipo e o método de autenticação diretamente. Compare esses valores com o que o dono do gateway diz que o concentrador aceita. Se o tipo não concorda com o chamado, corrija primeiro o chamado, porque isso é mais barato do que reinstalar um cliente que nunca esteve errado.
Estes quatro comandos cobrem o perfil, suas rotas, a tentativa de conexão e a acessibilidade da porta. Execute-os nessa ordem em uma máquina que já tenha o perfil instalado:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443O teste de porta é o que é lido em excesso. Um ouvinte TCP 443 que serve uma página de login e outro que encerra IKEv2 parecem idênticos de fora, porque a porta é um lugar e não um protocolo.
Escreva o resultado como três campos, cliente, modo e gateway, e mantenha-os ao lado do chamado. Qualquer coisa mais curta deixa a próxima pessoa redescobrir a mesma ambiguidade.