VPN de Windows fronte a Cisco Secure Client: cal é a correcta?
Unha marca non nomea un protocolo: Windows ofrece varios tipos nativos e o cliente de Cisco leva perfís para máis dun modo. Lea o perfil.
Para a mesma pasarela chegan dúas instrucións: conéctese coa VPN de Windows ou instale o cliente de Cisco. Ningunha das dúas nomea o intercambio que espera a pasarela, porque Windows expón varios tipos de conexión nativos e o cliente do fabricante leva perfís para máis dun modo. Ambas as etiquetas describen software, mentres que a pasarela negocia protocolo, autenticación e política. A resposta está no perfil, e pode lerse sen conectarse.
A etiqueta nomea software, non un intercambio
Unha marca e un sistema operativo son dous feitos distintos, e ningún dos dous escolle un formato de cable. Windows inclúe un conxunto de tipos nativos, e o cliente de Cisco inclúe un motor de perfís que pode manexar SSL ou IPsec/IKEv2. Confundir ambos produce táboas que comparan empresas en lugar de comparar intercambios.
A táboa seguinte substitúe a pregunta polo produto por tres lugares de lectura e o campo que garda cada un. Anote eses campos e a ambigüidade 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 referencia de Microsoft sobre os tipos de VPN de Windows enumera IKEv2 e SSTP entre os tipos nativos, o que descarta a idea de que un perfil nativo signifique PPTP. A documentación de perfís de Cisco describe tanto o modo SSL como o IPsec/IKEv2 coa política correspondente do concentrador. Cada fabricante ofrece varias opcións, así que ningún nome identifica un só protocolo.
Que poñen os tipos nativos no cable
IKEv2 negocia asociacións de seguridade sobre UDP e transporta o tráfico dentro de IPsec, o que o converte nun par doutras implementacións de IKEv2 e non nun deseño específico de Microsoft. SSTP envolve PPP dentro dunha sesión HTTPS, así que atravesa proxies que IKEv2 non pode e no cable parece TLS sen ser un protocolo VPN de TLS. Esas dúas feitos explican a maior parte dun ticket que informa de que o túnel funciona nunha rede e falla noutra.
L2TP con IPsec e a entrada máis antiga PPTP están no mesmo despregable, e a súa presenza alí non di nada sobre o soporte do servidor. Un despregable é un menú do que o sistema operativo pode intentar, non unha declaración de capacidades da pasarela. Leelo como unha lista de soporte é como comeza unha caza de credenciais de dúas horas.
Os campos que importan dun perfil nativo son o tipo de conexión, o método de autenticación e a identidade do servidor. O tipo equivocado falla nunha etapa distinta que un contrasinal malo, e esa diferenza é a pista que paga a pena seguir.
Que engade un cliente de fabricante: perfís, non un protocolo
O cliente de Cisco é un contedor de perfís. Un modo SSL e un modo IPsec/IKEv2 difiren en intercambio, expectativas de porto e texto de erro, e o perfil importado escolle entre ambos. Instalar o cliente, por tanto, non demostra nada sobre a accesibilidade.
As versións emparéllanse por unha razón. As funcións, os fluxos de autenticación e as comprobacións de postura négocianse entre cliente e concentrador, así que un cliente antigo contra un concentrador novo pode fallar dun xeito que se le como unha avaría de rede. Ese emparellamento pertence á definición de conexión, non a unha nota de actualización.
Un perfil exportado doutra organización raramente encaixa co concentrador local, e importalo pode deixar o cliente ofrecendo un modo que a pasarela non serve. Lea primeiro o modo do perfil e compareo despois co protocolo e a política de autenticación configurados na pasarela. Só cando coinciden a rede pasa a ser sospeitosa. Esa orde aforra unha captura de paquetes que tería mostrado unha sesión TLS san apuntando ao servizo equivocado.
Lea o perfil local antes de cambiar nada
En Windows a configuración nativa pódese ler sen marcar, e a saída nomea o tipo e o método de autenticación directamente. Compare eses valores co que o propietario da pasarela di que acepta o concentrador. Se o tipo non concorda co ticket, corrixa primeiro o ticket, porque iso é máis barato que reinstalar un cliente que nunca estivo equivocado.
Estes catro comandos cobren o perfil, as súas rutas, o intento de conexión e a accesibilidade do porto. Execúteos nesa orde nunha máquina que xa teña 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 443A proba do porto é a que se le de máis. Un oínte TCP 443 que serve unha páxina de inicio de sesión e outro que remata IKEv2 vense idénticos desde fóra, porque o porto é un lugar e non un protocolo.
Escriba o resultado como tres campos, cliente, modo e pasarela, e téñaos xunto ao ticket. Calquera cousa máis curta deixa á seguinte persoa redescubrir a mesma ambigüidade.