O proxy segue na dirección antiga do túnel tras reconectar a VPN?

Reiniciar o cliente VPN só demostra que o túnel volveu. Non di nada sobre o proxy ao que se lle dixo que saíse a través del. Squid, tinyproxy e a maioría dos demais reenviadores conservan a dirección de orixe local que resolveron ao arrincar ata que algo os obriga a recargar. Cando unha reconexión entrega unha nova dirección de túnel, o reenviador falla en cada conexión saínte ou comeza a saír pola túa ruta habitual.

Ese segundo fallo é o perigoso: o túnel está activo, as páxinas cargan e só a dirección de saída é incorrecta.

Comeza polo listener, non polo túnel

Hai tres direccións en xogo, e unha reconexión só move algunhas. O listener é onde apunta o teu navegador, normalmente 127.0.0.1 ou unha dirección de LAN, e non lle importa que o túnel cambiase. A orixe local saínte é o que o reenviador pide ao núcleo que use cando marca o seguinte salto, e está ligada ao dispositivo do túnel. A saída pública é o que rexistra un servidor web, que pode ser unha dirección traducida a varios saltos de distancia.

Unha consulta de IP pública só responde á última pregunta. Non pode dicirche a que dirección local debe ligarse un reenviador, porque unha soa saída pública pode ocultar varias fontes internas. Le a dirección de quen posúe a conexión: a saída de estado do cliente, a propia interface ou o espazo de nomes onde vive o túnel. Colle-la primeira interface cuxo nome pareza un túnel dá a resposta incorrecta en canto existe un segundo perfil.

Os deseños de contedores e espazos de nomes rompen ese suposto en silencio. Un reenviador nun espazo de nomes de rede non pode ligar un túnel que existe noutro, e ningunha cantidade de edición da configuración o arranxa.

Catro comprobacións antes de editar nada

Percórreas en orde. A primeira comprobación que falla é onde te detés, porque as posteriores supoñen que as anteriores se cumpren.

1. Confirma que o túnel en uso é o perfil ao redor do cal se construíu o proxy, non un segundo perfil que se conectou por si mesmo.
2. Imprime a dirección que hai agora nese dispositivo e compáraa coa dirección da configuración en execución.
3. Pregunta ao reenviador que orixe resolveu, en lugar do que afirma o ficheiro no disco.
4. Confirma que o tráfico do reenviador está realmente suxeito á política de encamiñamento e cortalumes que esperas.

A dirección do dispositivo é doada: ip -4 addr show dev tun0 imprime a actual, e ip -4 route get 1.1.1.1 mostra que interface escollería o núcleo para ese destino. Un reenviador que liga unha dirección exacta falla ruidosamente cando a dirección desaparece. Un reenviador que liga un dispositivo, ou recorre á orixe predeterminada, segue funcionando e filtrando, e ese é o resultado silencioso.

Axusta a documentación á versión que executas, non ao primeiro resultado de busca. A directiva de dirección saínte de Squid está documentada para v7 e anteriores, e a documentación de v8 di claramente que a directiva non está dispoñible alí, así que un script construído ao seu redor non sobrevive a esa fronteira (véxase a referencia Squid tcp_outgoing_address). Valida co analizador do propio produto antes de recargar nada: squid -k parse informa erros e sae sen tocar o proceso en execución.

Numera cada túnel e descarta os intercambios obsoletos

Unha reconexión é unha transferencia, e as transferencias necesitan unha orde. Etiqueta cada conexión observada cun contador ou unha marca de tempo que aumente en cada establecemento correcto, e despois leva esa etiqueta dentro da configuración candidata. Cando a etiqueta dun candidato é máis antiga que a actual, descarta o candidato en lugar de aplicalo, porque unha actualización lenta escrita para o túnel anterior sobrescribiría se non os axustes do actual. Unifica as ráfagas de eventos para que unha ligazón oscilante produza unha transición en lugar de quince.

Ordena o traballo en catro movementos: invalida o estado de saída antigo, espera a que o propietario da conexión informe da finalización, constrúe só o fragmento xestionado e despois valida e activa a través do xestor de servizos. Rexenerar todo o ficheiro a partir de dous valores de dirección é como desaparecen en silencio as restricións do listener, a autenticación e a política de destino. Respecta tamén unha parada deliberada. Un auxiliar que segue marcando un túnel que o usuario apagou é un erro, non unha resiliencia.

Os sockets abertos non seguirán a nova dirección

Reconfigurar o reenviador non di nada sobre as conexións xa establecidas. Se se esgotan ou morren depende do produto, así que observa o comportamento en lugar de supoñelo.

Unha petición servida por un socket aberto antes do cambio segue saíndo polo camiño antigo, mesmo cando a nova configuración é correcta. Se iso importa, decide explicitamente: permite unha ventá curta de esgotamento e deixa de admitir traballo novo, ou termina os sockets antigos e acepta os erros. Despois proba cunha conexión nova e mantén ese resultado separado da comprobación de esgotamento. Ligar a orixe tampouco é unha fronteira de seguridade. Cando o tráfico non deba tocar nunca a ruta habitual, impóno con marcas e regras de cortalumes, DNS e IPv6 incluídos, para que unha recarga fallida deixe o proxy explicitamente caído en lugar de aberto.

Demostra a nova saída cunha petición nova

O que importa é unha petición aberta despois da activación, non un ping nin unha páxina xa na caché. Pide ao proxy un URL real e le a dirección de saída que informa o extremo remoto, e compáraa coa visión que ten o cliente do túnel cando o provedor expón unha.

Mantén a análise, a recarga e a petición como comandos separados para que un fallo sinale un só paso. Os dous primeiros non cambian nada cando fallan, e é exactamente por iso que se executan antes do 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

Se a recarga falla, detén o servizo e repara o fragmento; un proxy que serve cunha saída obsoleta é peor que unha interrupción breve. Se a recarga ten éxito pero a petición nova segue saíndo nun lugar inesperado, volve á comprobación de encamiñamento en lugar de editar direccións outra vez. Anota a xeración do túnel contra a que validaches, para que a próxima reconexión teña algo concreto que comparar.