¿El proxy sigue en la dirección antigua del túnel tras reconectar la VPN?

Reiniciar el cliente VPN solo demuestra que el túnel ha vuelto. No dice nada sobre el proxy al que se le dijo que saliera a través de él. Squid, tinyproxy y la mayoría de los demás reenviadores conservan la dirección de origen local que resolvieron al arrancar hasta que algo los obliga a recargar. Cuando una reconexión entrega una nueva dirección de túnel, el reenviador falla en cada conexión saliente o empieza a salir por tu ruta ordinaria.

Ese segundo fallo es el peligroso: el túnel está activo, las páginas cargan y solo la dirección de salida es incorrecta.

Empieza por el listener, no por el túnel

Hay tres direcciones en juego, y una reconexión solo mueve algunas. El listener es donde apunta tu navegador, normalmente 127.0.0.1 o una dirección de LAN, y no le importa que el túnel haya cambiado. El origen local saliente es lo que el reenviador pide al núcleo que use cuando marca el siguiente salto, y está atado al dispositivo del túnel. La salida pública es lo que registra un servidor web, que puede ser una dirección traducida a varios saltos de distancia.

Una consulta de IP pública responde solo a la última pregunta. No puede decirte a qué dirección local debe enlazarse un reenviador, porque una sola salida pública puede ocultar varias fuentes internas. Lee la dirección de quien posee la conexión: la salida de estado del cliente, la propia interfaz o el espacio de nombres donde vive el túnel. Coger la primera interfaz cuyo nombre parezca un túnel da la respuesta equivocada en cuanto existe un segundo perfil.

Los diseños de contenedores y espacios de nombres rompen ese supuesto en silencio. Un reenviador en un espacio de nombres de red no puede enlazar un túnel que existe en otro, y ninguna cantidad de edición de configuración lo arregla.

Cuatro comprobaciones antes de editar nada

Recórrelas en orden. La primera comprobación que falla es donde te detienes, porque las posteriores suponen que las anteriores se cumplen.

1. Confirma que el túnel en uso es el perfil alrededor del cual se construyó el proxy, no un segundo perfil que se conectó por su cuenta.
2. Imprime la dirección que hay ahora en ese dispositivo y compárala con la dirección de la configuración en ejecución.
3. Pregunta al reenviador qué origen resolvió, en lugar de lo que afirma el archivo en disco.
4. Confirma que el tráfico del reenviador está realmente sujeto a la política de enrutamiento y cortafuegos que esperas.

La dirección del dispositivo es fácil: ip -4 addr show dev tun0 imprime la actual, y ip -4 route get 1.1.1.1 muestra qué interfaz elegiría el núcleo para ese destino. Un reenviador que enlaza una dirección exacta falla ruidosamente cuando la dirección desaparece. Un reenviador que enlaza un dispositivo, o recurre al origen predeterminado, sigue funcionando y filtrando, y ese es el resultado silencioso.

Ajusta la documentación a la versión que ejecutas, no al primer resultado de búsqueda. La directiva de dirección saliente de Squid está documentada para v7 y anteriores, y la documentación de v8 dice claramente que la directiva no está disponible allí, así que un script construido en torno a ella no sobrevive a esa frontera (véase la referencia Squid tcp_outgoing_address). Valida con el analizador del propio producto antes de recargar nada: squid -k parse informa errores y sale sin tocar el proceso en ejecución.

Numera cada túnel y descarta los intercambios obsoletos

Una reconexión es un traspaso, y los traspasos necesitan un orden. Etiqueta cada conexión observada con un contador o una marca de tiempo que aumente en cada establecimiento correcto, y luego lleva esa etiqueta dentro de la configuración candidata. Cuando la etiqueta de un candidato es más antigua que la actual, descarta el candidato en lugar de aplicarlo, porque una actualización lenta escrita para el túnel anterior sobrescribiría si no los ajustes del actual. Une las ráfagas de eventos para que un enlace oscilante produzca una transición en lugar de quince.

Ordena el trabajo en cuatro movimientos: invalida el estado de salida antiguo, espera a que el propietario de la conexión informe de la finalización, construye solo el fragmento gestionado y luego valida y activa a través del gestor de servicios. Regenerar todo el archivo a partir de dos valores de dirección es como desaparecen en silencio las restricciones del listener, la autenticación y la política de destino. Respeta también una parada deliberada. Un auxiliar que sigue marcando un túnel que el usuario apagó es un error, no una resiliencia.

Los sockets abiertos no seguirán la nueva dirección

Reconfigurar el reenviador no dice nada sobre las conexiones ya establecidas. Si se agotan o mueren depende del producto, así que observa el comportamiento en lugar de suponerlo.

Una petición atendida por un socket abierto antes del cambio sigue saliendo por el camino antiguo, incluso cuando la nueva configuración es correcta. Si eso importa, decide explícitamente: permite una ventana corta de agotamiento y deja de admitir trabajo nuevo, o termina los sockets antiguos y acepta los errores. Después prueba con una conexión nueva y mantén ese resultado separado de la comprobación de agotamiento. Enlazar el origen tampoco es una frontera de seguridad. Cuando el tráfico no deba tocar nunca la ruta ordinaria, impónlo con marcas y reglas de cortafuegos, DNS e IPv6 incluidos, para que una recarga fallida deje el proxy explícitamente caído en lugar de abierto.

Demuestra la nueva salida con una petición nueva

Lo que importa es una petición abierta después de la activación, no un ping ni una página ya almacenada en caché. Pide al proxy una URL real y lee la dirección de salida que informa el extremo remoto, y compárala con la visión que tiene el cliente del túnel cuando el proveedor expone una.

Mantén el análisis, la recarga y la petición como comandos separados para que un fallo apunte a un solo paso. Los dos primeros no cambian nada cuando fallan, y es exactamente por eso que se ejecutan antes del reinicio.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Si la recarga falla, detén el servicio y repara el fragmento; un proxy que sirve con una salida obsoleta es peor que una interrupción breve. Si la recarga tiene éxito pero la petición nueva sigue saliendo en un lugar inesperado, vuelve a la comprobación de enrutamiento en lugar de editar direcciones otra vez. Anota la generación del túnel contra la que validaste, para que la próxima reconexión tenga algo concreto que comparar.