¿Cómo convierte OpenConnect una cookie de inicio de sesión en un túnel?

OpenConnect enlaza dos intercambios separados con un único valor de vida corta: el inicio de sesión web y el túnel VPN. El primer intercambio es HTTPS corriente: las credenciales, un viaje de ida y vuelta SAML o un token van a la pasarela, y la respuesta lleva una cookie de autenticación. El segundo intercambio presenta esa cookie a la misma pasarela como prueba de que la fase web ya ocurrió, y solo entonces se levanta el túnel.

Durante el inicio de sesión no se negocia nada del túnel. Esa es la parte que vale la pena entender, porque la mayoría de los errores de script suponen que la cookie es una contraseña que hay que guardar, o una clave que protege el tráfico, cuando en realidad es un billete al portador para una sesión concreta de la pasarela.

Qué intercambian el cliente y la pasarela, por orden

La fase de autenticación parece un sitio web protegido normal. OpenConnect envía las credenciales del usuario, o sigue la redirección de la pasarela hacia un proveedor de identidad, y la pasarela responde con un documento que incrusta la cookie de autenticación. En el protocolo AnyConnect ese valor viaja en una cabecera de cookie en las peticiones siguientes, normalmente con un nombre como webvpn, y el manual lo trata como la credencial que lleva la sesión hacia delante.

La segunda fase es una petición CONNECT al punto final VPN de la pasarela con esa cookie adjunta. La pasarela la comprueba, asigna una dirección, y el cliente inicia CSTP sobre TLS, con DTLS como ruta de datos opcional más rápida una vez que existe la sesión. Solo en este punto se establecen los parámetros del túnel, las rutas, la configuración de DNS y las claves de tráfico de la sesión. La cookie hizo pasar al cliente por la puerta; no cifró nada.

Esta secuencia explica por qué existe openconnect --authenticate. Ejecútelo y realiza la fase web, imprime un pequeño bloque de variables de shell como COOKIE, HOST, CONNECT_URL y FINGERPRINT, y luego sale antes de construir ningún túnel. Un script envoltorio puede entonces iniciar la conexión real con esos valores, que es exactamente la división que necesita un despliegue sin interfaz o en dos contenedores.

La cookie es un portador de sesión, no una clave

Trate el valor como trataría un identificador de sesión en una aplicación web. Quien lo tenga durante su vida puede pedir a la pasarela el túnel al que esa sesión tiene derecho, así que su secreto importa. Pero copiarlo no revela tráfico, porque la confidencialidad del túnel viene del apretón de manos TLS y de las claves derivadas, no de la cadena de la cookie.

Tampoco es una concesión permanente. La pasarela y el proveedor de identidad deciden cuánto vive la sesión, y un navegador que aún muestra una página con sesión iniciada no dice nada sobre si la sesión del túnel sigue siendo válida. Volver a conectar tras el vencimiento significa repetir la fase web y producir una cookie nueva, y ese es el sentido de la reautenticación, no una molestia que haya que sortear con ingeniería.

No trate una cookie como sustituto universal de otras credenciales. Una aserción SAML, una contraseña de navegador y una cookie emitida por otro servicio son objetos distintos con audiencias distintas, y pegar una en el campo de la otra normalmente falla en la pasarela o, peor, tiene éxito contra el límite de confianza equivocado.

Entregar la cookie sin dejar copias

La entrega mecánica más segura en Linux es la entrada estándar. --cookie-on-stdin lee el valor de stdin, así que la cookie nunca aparece en la lista de argumentos del proceso, donde cualquier usuario local puede leerla con ps. Una tubería que autentica en un proceso y alimenta el túnel en otro mantiene el valor en una tubería en lugar de un archivo o una variable de entorno.

Los argumentos y las variables de entorno son más débiles por motivos distintos. Un argumento es visible en la tabla de procesos durante toda la vida del cliente y a menudo acaba en el historial del shell. Una variable de entorno se hereda a los procesos hijos, y una unidad de systemd que la define en el archivo de unidad guarda el secreto en una configuración legible. Si hace falta un archivo, restrínjalo a la cuenta de servicio y bórrelo cuando termine la sesión.

Mantenga también deliberado el límite de privilegios. El proceso que habla con el proveedor de identidad y quizá abre un navegador debería ejecutarse como el usuario dueño de ese inicio de sesión. El proceso que configura rutas, DNS y el dispositivo del túnel puede necesitar más privilegios. Ejecutar todo el navegador como root para que su cookie esté disponible para un túnel propiedad de root es el intercambio equivocado, y las configuraciones modernas de OpenConnect pueden pasar el valor por ese límite de forma explícita.

El registro merece la misma sospecha. La salida detallada del cliente, los scripts auxiliares y el diagnóstico de la pasarela pueden repetir material de la petición, y no todos los niveles de registro redactan la cookie. Capture el registro de error más pequeño que necesite, manténgalo fuera de canales compartidos y revise una muestra redactada antes de adjuntarla a un ticket.

Verificación y vencimiento en la segunda fase

La segunda fase todavía tiene que verificar el servidor. El FINGERPRINT que imprime --authenticate es un anclaje de certificado en forma pin-sha256:, y pasarlo a la invocación del túnel con --servercert mantiene la comprobación anclada a la pasarela contra la que se autenticó. Desactivar la comprobación de certificados para simplificar un script elimina la única prueba de que la cookie se entrega al host previsto.

Cuando la pasarela rechaza la cookie, la solución es una nueva ronda de autenticación, no una caché más larga. Guarde la cookie solo durante la vida de la conexión, borre los archivos temporales al salir y utilice el proceso de retirada de sesión del proveedor de identidad o de la pasarela cuando una sesión quede expuesta o se pierda un dispositivo. Una cookie en caché no es una exención de MFA.

Antes de automatizar esto, verifique cuatro cosas: el túnel se ejecuta con la cuenta correcta, la cookie llega por stdin, la huella del certificado está anclada y la sesión se descarta cuando el túnel se cierra. Si falta alguna, la automatización ha ampliado la confianza en la cookie en lugar de reproducir el flujo manual.