Amaga un cau de rutes VPN el teu canvi? Comprova tres coses

Buidar el cau de rutes és el primer instint quan un canvi no entra en vigor, i a Linux modern és un esforç inútil: el cau global de rutes IPv4 es va eliminar fa anys, així que ip route show cache no imprimeix res i no hi ha res a esborrar. L’estat que et enganya viu una capa més amunt: en un sòcol, una assignació NAT, un resolutor o un gestor de xarxa que ha tornat a aplicar el perfil antic. Tres preguntes separen aquests casos: el camí equivocat ve d’un flux nou o d’una connexió antiga, la teva plataforma desa rutes en cau o no, i l’estat és a l’encaminament o per sobre. Respon-les abans de reiniciar una interfície.

Primera comprovació: el camí antic ve d’un flux nou?

Una connexió establerta conserva la ruta amb què es va crear. Per això una sessió SSH pel túnel sobreviu a un canvi de la taula d’encaminament mentre una sessió nova pren immediatament el camí nou, i per això «el canvi no ha fet res» sovint vol dir «el sòcol antic encara el reté». Prova-ho amb un procés nou, no amb la finestra que ja tens oberta.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

L’última ordre imprimeix l’adreça a què ha arribat realment la connexió nova, que és la manera més barata de veure el camí real sense confiar en una finestra d’estat. Compara-la amb l’adreça d’origen que l’espai de noms o la interfície havien d’utilitzar.

Si un flux nou pren el camí correcte i l’antic no es recupera, deixa de mirar l’encaminament. La ruta era correcta; la sessió era antiga.

Segona comprovació: la teva plataforma guarda cap cau de rutes?

A Linux la resposta és no, en el sentit que volen dir la majoria de guies. No hi ha cap cau global de destinacions per llençar, i l’entrada per sòcol que guarda una ruta escollida s’allibera amb el sòcol. La secció de cau del manual d’ip-route descriu un comportament històric, no una cosa que puguis buidar en un nucli actual.

Altres plataformes són diferents, i aquí és on falla copiar consells. Windows guarda un cau de destinacions que pots netejar amb netsh interface ip delete destinationcache. BSD i macOS exposen cerques per destinació mitjançant route -n get, i els seus caus caduquen segons el seu propi calendari. Una ordre que funciona en una d’aquestes no fa res a Linux, i per això la mateixa solució sembla fallar a la meitat de qui la prova.

Una taula NAT o conntrack no és un cau de rutes, tot i que produeix el mateix símptoma. Un flux traduït abans del teu canvi conserva la seva traducció, i conntrack -L el mostrarà molt després que la política d’encaminament hagi canviat. Això és estat obsolet, però esborrar rutes no el tocarà.

Tercera comprovació: l’estat és a l’encaminament o per sobre?

Llegeix la consulta actual abans de llegir res més: ip route get per a la destinació, després la mateixa ordre amb from i l’adreça d’origen, després ip rule show. Si aquestes tres coincideixen amb el que volies, l’encaminament no és la capa a arreglar, i l’observació obsoleta ha vingut d’un altre lloc.

Tres sospitosos habituals seuen per sobre de l’encaminament. Un gestor de xarxa pot reinstal·lar una ruta des d’un perfil desat segons després que l’esborris, així que el teu canvi sembla revertir; comprova nmcli connection show --active i l’estat de la unitat abans de tornar a editar la taula. El cau d’un resolutor retorna una adreça antiga, que sembla una fallada d’encaminament fins que consultes el mateix nom amb una eina que trenca el cau. Una reserva de connexions d’una aplicació manté un sòcol funcional cap a la destinació antiga i no demana mai al nucli una decisió nova.

Què et permeten concloure les tres respostes

Ajunta les respostes i la reparació normalment es diu tota sola. Un flux nou que pren el camí equivocat en una plataforma sense cau de rutes vol dir que la política és realment incorrecta, així que llegeix les regles i la taula que el túnel ha instal·lat. Un flux nou que pren el camí correcte mentre la sessió antiga s’encalla vol dir que el problema és l’aplicació o el sòcol. Rutes correctes amb una observació trencada en tots dos casos vol dir que l’estat és per sobre de l’encaminament.

Resisteix l’actualització genèrica. Reiniciar la pila de xarxa o esborrar totes les rutes en una màquina el camí per defecte de la qual és el túnel pot tallar precisament la connexió que fas servir per arreglar-ho, i destrueix l’evidència que hauria dit quina capa ha fallat.

Si has de netejar alguna cosa, neteja la cosa més petita que encaixi amb el diagnòstic: els sòcols d’un procés, una entrada de conntrack, el cau del resolutor. Després repeteix la mateixa prova de flux nou i apunta què ha canviat.

Mantén els tres estats separats a les teves notes

La configuració desada, la consulta actual i el flux observat són tres fets diferents, i ajuntar-los en «el cau» és el que fa difícil reproduir la fallada. Apunta el perfil o la unitat que posseeix la ruta, la sortida de ip route get i l’origen i la destinació de la connexió real.

Anota-hi al costat la plataforma i la versió del client, perquè un remei que neteja un cau de destinacions de Windows no és un remei aplicable a un amfitrió Linux, i un procediment copiat entre tots dos ensenya la lliçó equivocada. Quan passis el problema a algú altre, aquestes tres línies li permetran reproduir l’estat fallit en lloc d’endevinar-lo.