VPN de Windows frente a Cisco Secure Client: ¿cuál es la correcta?
Una marca no nombra un protocolo: Windows ofrece varios tipos nativos y el cliente de Cisco lleva perfiles para más de un modo. Lea el perfil.
Para la misma puerta de enlace llegan dos instrucciones: conéctese con la VPN de Windows o instale el cliente de Cisco. Ninguna de las dos nombra el intercambio que espera la puerta de enlace, porque Windows expone varios tipos de conexión nativos y el cliente del fabricante lleva perfiles para más de un modo. Ambas etiquetas describen software, mientras que la puerta de enlace negocia protocolo, autenticación y política. La respuesta está en el perfil, y puede leerse sin conectarse.
La etiqueta nombra software, no un intercambio
Una marca y un sistema operativo son dos hechos distintos, y ninguno de los dos elige un formato de cable. Windows incluye un conjunto de tipos nativos, y el cliente de Cisco incluye un motor de perfiles que puede manejar SSL o IPsec/IKEv2. Confundir ambos produce tablas que comparan empresas en lugar de comparar intercambios.
La tabla siguiente sustituye la pregunta por el producto con tres lugares de lectura y el campo que guarda cada uno. Anote esos campos y la ambigüedad 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 |
La referencia de Microsoft sobre los tipos de VPN de Windows enumera IKEv2 y SSTP entre los tipos nativos, lo que descarta la idea de que un perfil nativo signifique PPTP. La documentación de perfiles de Cisco describe tanto el modo SSL como el IPsec/IKEv2 con la política correspondiente del concentrador. Cada fabricante ofrece varias opciones, así que ningún nombre identifica un solo protocolo.
Qué ponen los tipos nativos en el cable
IKEv2 negocia asociaciones de seguridad sobre UDP y transporta el tráfico dentro de IPsec, lo que lo convierte en un par de otras implementaciones de IKEv2 y no en un diseño específico de Microsoft. SSTP envuelve PPP dentro de una sesión HTTPS, así que atraviesa proxies que IKEv2 no puede y en el cable parece TLS sin ser un protocolo VPN de TLS. Esos dos hechos explican la mayor parte de un ticket que informa de que el túnel funciona en una red y falla en otra.
L2TP con IPsec y la entrada más antigua PPTP están en el mismo desplegable, y su presencia allí no dice nada sobre el soporte del servidor. Un desplegable es un menú de lo que el sistema operativo puede intentar, no una declaración de capacidades de la puerta de enlace. Leerlo como una lista de soporte es como empieza una cacería de credenciales de dos horas.
Los campos que importan de un perfil nativo son el tipo de conexión, el método de autenticación y la identidad del servidor. El tipo equivocado falla en una etapa distinta que una contraseña mala, y esa diferencia es la pista que merece seguirse.
Qué añade un cliente de fabricante: perfiles, no un protocolo
El cliente de Cisco es un contenedor de perfiles. Un modo SSL y un modo IPsec/IKEv2 difieren en intercambio, expectativas de puerto y texto de error, y el perfil importado elige entre ambos. Instalar el cliente, por tanto, no demuestra nada sobre la accesibilidad.
Las versiones se emparejan por una razón. Las funciones, los flujos de autenticación y las comprobaciones de postura se negocian entre cliente y concentrador, así que un cliente antiguo contra un concentrador nuevo puede fallar de una forma que se lee como una avería de red. Ese emparejamiento pertenece a la definición de conexión, no a una nota de actualización.
Un perfil exportado de otra organización rara vez encaja con el concentrador local, e importarlo puede dejar al cliente ofreciendo un modo que la puerta de enlace no sirve. Lea primero el modo del perfil y compárelo después con el protocolo y la política de autenticación configurados en la puerta de enlace. Solo cuando coinciden la red pasa a ser sospechosa. Ese orden ahorra una captura de paquetes que habría mostrado una sesión TLS sana apuntando al servicio equivocado.
Lea el perfil local antes de cambiar nada
En Windows la configuración nativa puede leerse sin marcar, y la salida nombra el tipo y el método de autenticación directamente. Compare esos valores con lo que el propietario de la puerta de enlace dice que acepta el concentrador. Si el tipo no concuerda con el ticket, corrija primero el ticket, porque eso es más barato que reinstalar un cliente que nunca estuvo equivocado.
Estos cuatro comandos cubren el perfil, sus rutas, el intento de conexión y la accesibilidad del puerto. Ejecútelos en ese orden en una máquina que ya tenga el 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 443La prueba del puerto es la que se lee de más. Un escucha TCP 443 que sirve una página de inicio de sesión y otro que termina IKEv2 se ven idénticos desde fuera, porque el puerto es un lugar y no un protocolo.
Escriba el resultado como tres campos, cliente, modo y puerta de enlace, y téngalos junto al ticket. Cualquier cosa más corta deja a la siguiente persona redescubrir la misma ambigüedad.