Wi-Fi público y VPN: lo que el túnel no cubre

Insignia verde, portal conforme, navegador que funciona: esa es toda la historia visible. Lo que la insignia omite es que la conexión cifrada la transporta precisamente el enlace inalámbrico del que debería protegerte. Ese enlace sigue entregando cada paquete, sigue viendo la dirección de destino y sigue decidiendo si algo llega. Recorrer el lado del portátil de una conexión de hotel muestra qué partes cubre el túnel y cuáles te deja a ti.

El enlace de acceso lo transporta todo

Un túnel IPsec ESP envuelve un paquete interior protegido dentro de una cabecera exterior que la red puede encaminar, y RFC 4303 sección 3.1.2 expone esa división. El paquete interior es lo que protege el túnel. La cabecera exterior es lo que lee el punto de acceso para reenviarlo. Otros diseños encapsulan de otra forma, pero la pregunta de planificación es idéntica: ¿qué camino de acceso transporta esta conexión?

Un fallo de la puerta de enlace o un enlace que descarta paquetes detiene la entrega sin revelar el contenido. Cambiar a un cifrado más fuerte no sirve para eso, porque la pieza que falta es el transporte, no la criptografía. Una entrega correcta demuestra igual de poco en la otra dirección, ya que un camino que funciona no dice nada sobre el estado de ninguna de las dos máquinas.

Tu portátil sigue teniendo sus propias puertas

Unirse a un segmento no confiable cambia quién puede alcanzar los puertos en los que escucha tu máquina. Un servicio de uso compartido de archivos, un agente de administración remota o un servidor de desarrollo vinculado a todas las interfaces es accesible para cualquiera de ese segmento a menos que algo lo detenga. El tráfico que nunca entra en el túnel no queda protegido por él. Un oyente que responde antes de que el túnel esté activo queda expuesto exactamente durante esa ventana.

El requisito es estrecho y merece enunciarse con precisión: el portátil debe alcanzar el extremo de la VPN, y los dispositivos no relacionados del punto de acceso no deben alcanzar los servicios locales. Las reglas del cortafuegos del equipo expresan esa frontera, y la propia configuración de uso compartido de la plataforma también expresa parte de ella. Una impresora o un paso del portal es una excepción acotada que añades deliberadamente, no una prueba de que todo el punto de acceso merezca la confianza de una LAN de oficina.

Algunas organizaciones también restringen el acceso local mientras hay una conexión de trabajo activa, lo que es política y no ingeniería. Lee esa política antes de desactivar un cortafuegos para hacer funcionar un periférico.

Comprueba qué está escuchando de verdad

Mira los sockets y no la página de configuración, porque la página describe la intención y la tabla de sockets describe la máquina. Las dos listas de abajo separan cada socket que escucha de los que un vecino podría alcanzar. Ejecútalas en el segmento no confiable antes de conectar el túnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

El primer comando muestra cada socket, y el segundo filtra los que están vinculados más allá del loopback. Un servicio en 0.0.0.0 o en :: está disponible en todas las interfaces, incluida la inalámbrica, mientras que el mismo servicio en 127.0.0.1 no es accesible desde el segmento en absoluto. La consulta al resolutor confirma qué camino toma el nombre antes de que exista el túnel, y ahí es donde interfieren los portales cautivos. Repite la lista después de conectar, porque algunos clientes levantan interfaces que cambian la respuesta.

Un puerto que solo aparece mientras el túnel está activo está menos expuesto, aunque sigue mereciendo conocerse. Anota la diferencia y no la lista absoluta, ya que el delta es lo que añadió el túnel.

No aceptes una identidad nueva a mitad de sesión

Un cambio de ruta inesperado, una reconexión o una redirección del portal no son permiso para aceptar una identidad de servidor distinta. Si el cliente informa de una discrepancia de certificado o de clave, trátala como un hallazgo de identidad y no como una conectividad que haya que sortear. Instalar un certificado raíz sin explicación para que funcione un portal convierte un problema de entrega en un problema de confianza. Y el problema de confianza sobrevive después al viaje que lo creó.

Usa el flujo de navegador propio del portal, luego reconecta el túnel y lee el registro del cliente para saber qué identidad verificó. Un fallo de identidad significa que el par no es quien esperabas, mientras que un fallo de entrega significa que el par nunca respondió. El primero es motivo para detenerse, y el segundo es motivo para probar otro camino.

Decide primero el comportamiento ante una caída

Aquí se confunden dos funciones distintas. La reconexión intenta restablecer el servicio, mientras que una política de bloqueo controla qué tráfico se permite mientras el túnel está caído. Ninguna proporciona un enlace inalámbrico que funcione, y ninguna demuestra que el extremo esté limpio. Elige explícitamente: fallo cerrado para las aplicaciones que nunca deben usar el camino local, y permitir la navegación normal fuera del túnel si eso es aceptable.

Anota la elección, porque el valor predeterminado en la mayoría de los clientes no es ninguno de los dos, y varía según la versión. Después dispón un camino de acceso alternativo si la disponibilidad importa, como un punto de acceso telefónico con su propio plan de datos. Una prueba de aceptación aceptable tiene tres resultados separados: el tráfico previsto usa el túnel verificado, los oyentes locales no relacionados son inaccesibles, y una caída produce el comportamiento que elegiste.