SSL VPN heredado en IOS: paquete, perfil, puerta de enlace y sesión

Encuentra un instalador de cliente en la flash del router y concluye que el SSL VPN está configurado. Eso es un componente de cuatro, y los otros tres deciden si alguien puede conectarse. En el SSL VPN heredado de IOS las piezas son objetos distintos: el paquete de cliente de cabecera, un perfil de cliente opcional, la puerta de enlace WebVPN que termina TLS y el contexto junto con la política de grupo que guardan la autenticación y los ajustes de sesión. Si falta uno, el fallo se ve igual desde fuera.

El ejemplo de configuración de SSL VPN de Cisco IOS, construido sobre IOS 15.3 con AnyConnect 3.1, es útil precisamente porque mantiene esos objetos separados. Léalo como una descripción de aquella implementación anterior, no como una recomendación de desplegar esas versiones.

Primero, el paquete: qué es y qué no es

El paquete de cabecera proporciona software de cliente para una plataforma. No es ni el perfil ni el punto de escucha, y un archivo que está en la flash solo demuestra que alguien subió algo. No demuestra que una sesión lo haya usado alguna vez, que la plataforma coincida con el dispositivo del usuario ni que la puerta de enlace lo referencie siquiera.

Confirme el nombre exacto del archivo, la plataforma a la que apunta y dónde lo referencia la configuración. Un paquete de Windows no le dice nada sobre teléfonos, y un archivo subido que ningún objeto de puerta de enlace menciona es almacenamiento y no configuración. Un paquete que coincide con la plataforma pero nunca se asocia al servicio no se ofrecerá a ningún usuario. Tampoco uno cuyo nombre de archivo difiera del valor que espera la configuración.

Segundo, el perfil: ajustes en lugar de software

Un perfil de cliente opcional lleva ajustes que un administrador prepara por separado, como listas de servidores o preferencias del cliente. Confundirlo con un instalador es habitual porque ambos llegan como archivos con nombres parecidos. Si el despliegue espera un perfil, su ausencia cambia lo que el cliente hace después de conectarse, no si se conecta.

Inventaríe ambos artefactos y anote a cuál hace referencia realmente la puerta de enlace. Esa única línea evita toda una clase de tickets de soporte en los que dos personas hablan de archivos distintos.

Tercero, el punto de escucha y la identidad TLS

El objeto de puerta de enlace define la dirección y el puerto que alcanza el mundo exterior y el certificado que se presenta durante el handshake. Un navegador que llega a una página de portal, un cliente que completa la autenticación y una aplicación que llega a un servidor privado son tres observaciones distintas, y solo la primera es una prueba del punto de escucha. Cuando el handshake falla, nada aguas abajo importa todavía, así que verifique la cadena de certificados y el nombre antes de editar cualquier política.

Anote en algún sitio la identidad esperada. Un certificado renovado o sustituido es la razón más frecuente por la que un despliegue que funcionaba el mes pasado deja de funcionar este.

Cuarto, el contexto y la política con su plantilla virtual

El contexto y la política de grupo vinculan la autenticación al comportamiento de la sesión: grupo de direcciones, rutas divididas, DNS y a qué redes internas puede llegar un usuario. El ejemplo documentado enlaza su contexto a una plantilla virtual que aporta el comportamiento de interfaz por sesión, y esos objetos del lado del servidor existen con independencia de lo que descargue un usuario.

Cuando un usuario se autentica pero no llega a nada, el fallo suele estar aquí y no en el cliente. Compare el grupo, las rutas entregadas al cliente y la ACL que permite el tráfico hacia delante, y contrástelos con lo que informa el usuario y no con lo que pretendía el diseño.

Verifique en orden y deténgase en el primer fallo

Recorra los cuatro componentes en el orden en que una conexión los encuentra: punto de escucha, autenticación, política y después el comportamiento del cliente. Confirme TLS con la identidad esperada, autentique una cuenta que se sabe buena, lea la dirección y las rutas asignadas desde la sesión y solo después compare la plataforma del cliente con el paquete. Detenerse en el primer fallo mantiene una sola variable en juego, y esa es la diferencia entre una reparación y una suposición.

Para un teléfono o cualquier cliente fuera de ese ejemplo histórico de escritorio, obtenga el contrato real de cliente y puerta de enlace que esté soportado en lugar de suponer que el flujo de Windows se generaliza. Cambiar un protocolo solicitado no convertirá un perfil IKEv2 en este servicio SSL VPN, e instalar un paquete de escritorio no demuestra nada sobre soporte móvil.