Como converte OpenConnect unha cookie de inicio de sesión nun túnel?

OpenConnect liga dous intercambios separados cun único valor de vida curta: o inicio de sesión web e o túnel VPN. O primeiro intercambio é HTTPS corrente: as credenciais, unha viaxe de ida e volta SAML ou un token van á pasarela, e a resposta leva unha cookie de autenticación. O segundo intercambio presenta esa cookie á mesma pasarela como proba de que a fase web xa ocorreu, e só entón se levanta o túnel.

Durante o inicio de sesión non se negocia nada do túnel. Esa é a parte que paga a pena entender, porque a maioría dos erros de script supoñen que a cookie é un contrasinal para gardar, ou unha chave que protexe o tráfico, cando en realidade é un billete ao portador para unha sesión concreta da pasarela.

Que intercambian o cliente e a pasarela, por orde

A fase de autenticación parece un sitio web protexido normal. OpenConnect envía as credenciais do usuario, ou segue a redirección da pasarela cara a un provedor de identidade, e a pasarela responde cun documento que incrusta a cookie de autenticación. No protocolo AnyConnect ese valor viaxa nunha cabeceira de cookie nas peticións seguintes, normalmente cun nome como webvpn, e o manual trátao como a credencial que leva a sesión adiante.

A segunda fase é unha petición CONNECT ao punto final VPN da pasarela con esa cookie axunta. A pasarela compróbaa, asigna un enderezo, e o cliente inicia CSTP sobre TLS, con DTLS como ruta de datos opcional máis rápida unha vez que existe a sesión. Só neste punto se establecen os parámetros do túnel, as rutas, a configuración de DNS e as chaves de tráfico da sesión. A cookie fixo pasar o cliente pola porta; non cifrou nada.

Esta secuencia explica por que existe openconnect --authenticate. Execúteo e realiza a fase web, imprime un pequeno bloque de variables de shell como COOKIE, HOST, CONNECT_URL e FINGERPRINT, e despois sae antes de construír ningún túnel. Un script envoltorio pode entón iniciar a conexión real con eses valores, que é exactamente a división que necesita un despregamento sen interface ou en dous contedores.

A cookie é un portador de sesión, non unha chave

Trate o valor como trataría un identificador de sesión nunha aplicación web. Quen o teña durante a súa vida pode pedir á pasarela o túnel ao que esa sesión ten dereito, así que o seu segredo importa. Pero copialo non revela tráfico, porque a confidencialidade do túnel vén do apretón de mans TLS e das chaves derivadas, non da cadea da cookie.

Tampouco é unha concesión permanente. A pasarela e o provedor de identidade deciden canto vive a sesión, e un navegador que aínda mostra unha páxina con sesión iniciada non di nada sobre se a sesión do túnel segue sendo válida. Volver conectar tras o vencemento significa repetir a fase web e producir unha cookie nova, e ese é o sentido da reautenticación, non unha molestia que hai que sortear con enxeñaría.

Non trate unha cookie como substituto universal doutras credenciais. Unha aserción SAML, un contrasinal de navegador e unha cookie emitida por outro servizo son obxectos distintos con audiencias distintas, e pegar unha no campo da outra normalmente falla na pasarela ou, peor, ten éxito contra o límite de confianza equivocado.

Entregar a cookie sen deixar copias

A entrega mecánica máis segura en Linux é a entrada estándar. --cookie-on-stdin le o valor de stdin, así que a cookie nunca aparece na lista de argumentos do proceso, onde calquera usuario local pode lela con ps. Unha tubaxe que autentica nun proceso e alimenta o túnel noutro mantén o valor nunha tubaxe en lugar dun ficheiro ou unha variable de contorno.

Os argumentos e as variables de contorno son máis febles por motivos distintos. Un argumento é visible na táboa de procesos durante toda a vida do cliente e a miúdo acaba no historial da consola. Unha variable de contorno hérdase aos procesos fillos, e unha unidade de systemd que a define no ficheiro de unidade garda o segredo nunha configuración lexible. Se cómpre un ficheiro, restrínxao á conta de servizo e bórrao cando remate a sesión.

Manteña tamén deliberado o límite de privilexios. O proceso que fala co provedor de identidade e quizais abre un navegador debería correr como o usuario dono dese inicio de sesión. O proceso que configura rutas, DNS e o dispositivo do túnel pode necesitar máis privilexios. Executar todo o navegador como root para que a súa cookie estea dispoñible para un túnel propiedade de root é o intercambio equivocado, e as configuracións modernas de OpenConnect poden pasar o valor por ese límite de forma explícita.

O rexistro merece a mesma sospeita. A saída detallada do cliente, os scripts auxiliares e o diagnóstico da pasarela poden repetir material da petición, e non todos os niveis de rexistro redactan a cookie. Capture o rexistro de erro máis pequeno que necesite, mantéñao fóra de canles compartidas e revise unha mostra redactada antes de adxuntala a un tícket.

Verificación e vencemento na segunda fase

A segunda fase aínda ten que verificar o servidor. O FINGERPRINT que imprime --authenticate é unha fixación de certificado en forma pin-sha256:, e pasalo á invocación do túnel con --servercert mantén a comprobación ancorada á pasarela contra a que se autenticou. Desactivar a comprobación de certificados para simplificar un script elimina a única proba de que a cookie se entrega ao host previsto.

Cando a pasarela rexeita a cookie, a solución é unha nova rolda de autenticación, non unha caché máis longa. Garde a cookie só durante a vida da conexión, borre os ficheiros temporais ao saír e utilice o proceso de retirada de sesión do provedor de identidade ou da pasarela cando unha sesión quede exposta ou se perda un dispositivo. Unha cookie en caché non é unha exención de MFA.

Antes de automatizar isto, verifique catro cousas: o túnel corre coa conta correcta, a cookie chega por stdin, a impresión do certificado está fixada e a sesión descártase cando o túnel se pecha. Se falta algunha, a automatización ampliou a confianza na cookie en lugar de reproducir o fluxo manual.