Ascunde un cache de rute VPN modificarea ta? Verifică trei lucruri

Golirea cache-ului de rute este primul instinct când o modificare nu intră în vigoare, iar pe Linux modern este efort irosit: cache-ul global de rute IPv4 a fost eliminat acum ani, așa că ip route show cache nu afișează nimic și nu e nimic de șters. Starea care te păcălește trăiește un nivel mai sus: într-un socket, o mapare NAT, un resolver sau un manager de rețea care a reaplicat profilul vechi. Trei întrebări separă aceste cazuri: dacă calea greșită vine dintr-un flux nou sau dintr-o conexiune veche, dacă platforma ta ține rutele în cache, și dacă starea este în rutare sau deasupra ei. Răspunde-le înainte de a reseta o interfață.

Verificarea unu: calea veche vine dintr-un flux nou?

O conexiune stabilită păstrează ruta cu care a fost creată. De aceea o sesiune SSH prin tunel supraviețuiește unei modificări a tabelei de rutare, în timp ce o sesiune nouă preia imediat calea nouă, și de aceea „modificarea nu a făcut nimic” înseamnă adesea „socketul vechi încă o ține”. Testează cu un proces nou, nu cu fereastra pe care o ai deja deschisă.

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

Ultima comandă afișează adresa pe care conexiunea nouă a atins-o efectiv, iar aceasta este cea mai ieftină cale de a vedea calea reală fără să te bazezi pe o fereastră de stare. Compar-o cu adresa sursă pe care spațiul de nume sau interfața ar fi trebuit să o folosească.

Dacă un flux nou ia calea corectă, iar cel vechi nu se recuperează, oprește-te din privit rutarea. Ruta era corectă; sesiunea era veche.

Verificarea doi: platforma ta ține măcar un cache de rute?

Pe Linux răspunsul este nu, în sensul la care se referă majoritatea ghidurilor. Nu există un cache global de destinații de aruncat, iar intrarea la nivel de socket care ține o rută aleasă este eliberată împreună cu socketul. Secțiunea de cache din manualul ip-route descrie un comportament istoric, nu ceva ce poți goli pe un kernel actual.

Alte platforme diferă, și exact aici copierea sfaturilor merge greșit. Windows ține un cache de destinații pe care îl poți curăța cu netsh interface ip delete destinationcache. BSD și macOS expun căutări pentru fiecare destinație prin route -n get, iar cache-urile lor expiră după propriul calendar. O comandă care funcționează pe una dintre ele nu face absolut nimic pe Linux, de aceea aceeași remediere pare să eșueze pentru jumătate dintre cei care o încearcă.

Un tabel NAT sau conntrack nu este un cache de rute, deși produce același simptom. Un flux tradus înainte de modificarea ta își păstrează traducerea, iar conntrack -L îl va arăta mult după ce politica de rutare a mers mai departe. Aceea este o stare învechită, dar ștergerea rutelor nu o va atinge.

Verificarea trei: starea este în rutare sau deasupra ei?

Citește căutarea curentă înainte de orice altceva: ip route get pentru destinație, apoi aceeași comandă cu from și adresa sursă, apoi ip rule show. Dacă aceste trei se potrivesc cu ce ai intenționat, rutarea nu este stratul de reparat, iar observația învechită a venit de altundeva.

Trei suspecți obișnuiți stau deasupra rutării. Un manager de rețea poate reinstala o rută dintr-un profil salvat la câteva secunde după ce o ștergi, așa că modificarea ta pare să revină; verifică nmcli connection show --active și starea unității înainte de a edita din nou tabela. Cache-ul unui resolver returnează o adresă veche, ceea ce pare o defecțiune de rutare până când interoghezi același nume cu un instrument care ocolește cache-ul. Pool-ul de conexiuni al unei aplicații ține un socket funcțional către destinația veche și nu cere niciodată kernelului o decizie nouă.

Ce îți permit cele trei răspunsuri să concluzionezi

Pune răspunsurile împreună și remedierea se enunță de obicei singură. Un flux nou care ia calea greșită pe o platformă fără cache de rute înseamnă că politica este într-adevăr greșită, așa că citește regulile și tabela pe care le-a instalat tunelul. Un flux nou care ia calea corectă în timp ce sesiunea veche se blochează înseamnă că problema este aplicația sau socketul. Rute corecte cu o observație stricată în ambele cazuri înseamnă că starea este deasupra rutării.

Rezistă reîmprospătării generice. Repornirea stivei de rețea sau ștergerea fiecărei rute pe o mașină a cărei rută implicită este tunelul poate tăia exact conexiunea pe care o folosești ca să o repari, și distruge dovada care ți-ar fi spus ce strat a eșuat.

Dacă tot trebuie să cureți ceva, curăță cel mai mic lucru care se potrivește cu diagnosticul: socketurile unui proces, o intrare conntrack, cache-ul resolverului. Apoi repetă același test de flux nou și notează ce s-a schimbat.

Ține cele trei stări separate în notițele tale

Configurația salvată, căutarea curentă și fluxul observat sunt trei fapte diferite, iar contopirea lor în „cache” este ce face defectul greu de reprodus. Notează profilul sau unitatea care deține ruta, ieșirea lui ip route get, și sursa și destinația conexiunii reale.

Notează alături platforma și versiunea clientului, pentru că o remediere care curăță un cache de destinații Windows nu este o remediere aplicabilă unui host Linux, iar o procedură copiată între ele predă lecția greșită. Când dai problema altcuiva, acele trei linii îi permit să reproducă starea defectă în loc să ghicească.