El proxy encara és a l’adreça antiga del túnel després de reconnectar la VPN?

Reiniciar el client VPN només demostra que el túnel ha tornat. No diu res sobre el proxy que havia de sortir a través seu. Squid, tinyproxy i la majoria d’altres reenviadors conserven l’adreça d’origen local que van resoldre en arrencar fins que alguna cosa els obliga a recarregar. Quan una reconnexió assigna una adreça de túnel nova, el reenviador falla a cada connexió sortint o comença a sortir per la vostra ruta ordinària.

Aquesta segona fallada és la perillosa: el túnel funciona, les pàgines carreguen i només l’adreça de sortida és incorrecta.

Comenceu pel listener, no pel túnel

Hi ha tres adreces en joc, i una reconnexió només en mou algunes. El listener és on apunta el vostre navegador, normalment 127.0.0.1 o una adreça de LAN, i no li importa que el túnel hagi canviat. L’origen local sortint és el que el reenviador demana al nucli quan marca el següent salt, i està lligat al dispositiu del túnel. La sortida pública és el que registra un servidor web, que pot ser una adreça traduïda a diversos salts de distància.

Una consulta d’IP pública només respon a l’última pregunta. No us pot dir a quina adreça local s’ha de lligar un reenviador, perquè una sola sortida pública pot amagar diversos orígens interns. Llegiu l’adreça de qui posseeix la connexió: la sortida d’estat del client, la interfície mateixa o l’espai de noms on viu el túnel. Agafar la primera interfície el nom de la qual sembla un túnel dona la resposta equivocada tan bon punt existeix un segon perfil.

Els dissenys de contenidors i d’espais de noms trenquen aquest supòsit en silenci. Un reenviador en un espai de noms de xarxa no pot lligar un túnel que existeix en un altre, i cap quantitat d’edició de configuració ho arregla.

Quatre comprovacions abans d’editar res

Feu-les en ordre. La primera comprovació que falla és on us atureu, perquè les posteriors assumeixen que les anteriors es compleixen.

1. Confirmeu que el túnel en ús és el perfil al voltant del qual es va construir el proxy, no un segon perfil que s’ha connectat sol.
2. Imprimiu l’adreça que hi ha actualment en aquest dispositiu i compareu-la amb l’adreça de la configuració en execució.
3. Pregunteu al reenviador quin origen ha resolt, en lloc del que afirma el fitxer al disc.
4. Confirmeu que el trànsit del reenviador està realment subjecte a la política d’encaminament i de tallafocs que espereu.

L’adreça del dispositiu és fàcil: ip -4 addr show dev tun0 imprimeix la actual, i ip -4 route get 1.1.1.1 mostra quina interfície triaria el nucli per a aquesta destinació. Un reenviador que lliga una adreça exacta falla sorollosament quan l’adreça desapareix. Un reenviador que lliga un dispositiu, o que recorre a l’origen per defecte, continua funcionant i filtrant, i aquest és el resultat silenciós.

Feu coincidir la documentació amb la versió que executeu, no amb el primer resultat de cerca. La directiva d’adreça sortint de Squid està documentada per a v7 i anteriors, i la documentació de v8 diu clarament que la directiva no hi és disponible, així que un script construït al seu voltant no sobreviu a aquesta frontera (vegeu la referència Squid tcp_outgoing_address). Valideu amb l’analitzador del mateix producte abans de recarregar res: squid -k parse informa d’errors i surt sense tocar el procés en execució.

Numereu cada túnel i descarteu els intercanvis obsolets

Una reconnexió és un traspàs, i els traspassos necessiten un ordre. Etiqueteu cada connexió observada amb un comptador o una marca de temps que augmenta a cada establiment correcte, i després porteu aquesta etiqueta dins de la configuració candidata. Quan l’etiqueta d’un candidat és més antiga que la actual, descarteu el candidat en lloc d’aplicar-lo, perquè una actualització lenta escrita per al túnel anterior sobreescriurà si no els paràmetres del túnel actual. Uniu les ràfegues d’esdeveniments perquè un enllaç oscil·lant produeixi una transició en lloc de quinze.

Ordeneu la feina en quatre moviments: invalideu l’estat de sortida antic, espereu que el propietari de la connexió informi de la finalització, construïu només el fragment gestionat i, després, valideu i activeu a través del gestor de serveis. Regenerar tot el fitxer a partir de dos valors d’adreça és com les restriccions del listener, l’autenticació i la política de destinació desapareixen en silenci. Respecteu també una aturada deliberada. Un auxiliar que continua marcant un túnel que l’usuari ha apagat és un error, no una resiliència.

Els sockets oberts no seguiran l’adreça nova

Reconfigurar el reenviador no diu res sobre les connexions ja establertes. Si s’esgoten o moren depèn del producte, així que observeu el comportament en lloc de suposar-lo.

Una petició servida per un socket obert abans del canvi continua sortint pel camí antic, fins i tot quan la configuració nova és correcta. Si això importa, decidiu explícitament: permeteu una finestra curta d’esgotament i deixeu d’admetre feina nova, o tanqueu els sockets antics i accepteu els errors. Després proveu amb una connexió nova i manteniu aquest resultat separat de la comprovació d’esgotament. Lligar l’origen tampoc no és una frontera de seguretat. Quan el trànsit no hagi de tocar mai la ruta ordinària, forceu-ho amb marques i regles de tallafocs, DNS i IPv6 inclosos, perquè una recàrrega fallida deixi el proxy explícitament aturat en lloc d’obert.

Demostreu la sortida nova amb una petició nova

El que importa és una petició oberta després de l’activació, no un ping ni una pàgina ja emmagatzemada a la memòria cau. Demaneu al proxy un URL real i llegiu l’adreça de sortida que informa l’extrem remot, i compareu-la amb la visió que té el client del túnel quan el proveïdor n’exposa una.

Manteniu l’anàlisi, la recàrrega i la petició com a ordres separades perquè una fallada assenyali un sol pas. Les dues primeres no canvien res quan fallen, i és exactament per això que s’executen abans del reinici.

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 recàrrega falla, atureu el servei i repareu el fragment; un proxy que serveix amb una sortida obsoleta és pitjor que una interrupció curta. Si la recàrrega té èxit però la petició nova encara surt en un lloc inesperat, torneu a la comprovació d’encaminament en lloc de tornar a editar adreces. Anoteu la generació del túnel contra la qual heu validat, perquè la propera reconnexió tingui alguna cosa concreta per comparar.