Czy pamięć podręczna tras VPN ukrywa Twoją zmianę? Sprawdź trzy rzeczy

Czyszczenie pamięci podręcznej tras to pierwszy odruch, gdy zmiana nie działa, a na nowoczesnym Linuksie to strata czasu: globalna pamięć podręczna tras IPv4 została usunięta lata temu, więc ip route show cache nic nie wypisuje i nie ma czego czyścić. Stan, który Cię zwodzi, mieszka o warstwę wyżej: w sockecie, mapowaniu NAT, resolverze lub menedżerze sieci, który ponownie zastosował stary profil. Trzy pytania rozdzielają te przypadki: czy zła ścieżka pochodzi z nowego przepływu czy starego połączenia, czy Twoja platforma w ogóle cachuje trasy, i czy stan jest w routingu, czy nad nim. Odpowiedz na nie, zanim zresetujesz interfejs.

Kontrola pierwsza: czy stara ścieżka pochodzi z nowego przepływu?

Ustanowione połączenie zachowuje trasę, z którą zostało utworzone. Dlatego sesja SSH przez tunel przeżywa zmianę tabeli routingu, podczas gdy nowa sesja od razu wybiera nową ścieżkę, i dlatego „zmiana nic nie zrobiła” często znaczy „stary socket wciąż ją trzyma”. Testuj nowym procesem, a nie oknem, które już masz otwarte.

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

Ostatnie polecenie wypisuje adres, który nowe połączenie faktycznie osiągnęło, i to najtańszy sposób zobaczenia rzeczywistej ścieżki bez zaufania oknu stanu. Porównaj go z adresem źródłowym, którego miał użyć namespace lub interfejs.

Jeśli nowy przepływ wybiera właściwą ścieżkę, a stary się nie podnosi, przestań patrzeć na routing. Trasa była właściwa; sesja była stara.

Kontrola druga: czy Twoja platforma w ogóle trzyma pamięć podręczną tras?

Na Linuksie odpowiedź brzmi nie, w sensie, jaki ma na myśli większość poradników. Nie ma globalnej pamięci podręcznej miejsc docelowych do wyrzucenia, a wpis na poziomie socketa, który trzyma wybraną trasę, jest zwalniany razem z socketem. Sekcja pamięci podręcznej w podręczniku ip-route opisuje historyczne zachowanie, a nie coś, co możesz wyczyścić na bieżącym jądrze.

Inne platformy różnią się i właśnie tutaj kopiowanie porad idzie źle. Windows trzyma pamięć podręczną miejsc docelowych, którą możesz wyczyścić poleceniem netsh interface ip delete destinationcache. BSD i macOS udostępniają wyszukiwania dla każdego miejsca docelowego przez route -n get, a ich pamięci podręczne wygasają według własnego harmonogramu. Polecenie, które działa na jednej z nich, na Linuksie nie robi zupełnie nic, dlatego ta sama poprawka wydaje się zawodzić u połowy ludzi, którzy ją wypróbowują.

Tabela NAT lub conntrack nie jest pamięcią podręczną tras, choć daje ten sam objaw. Przepływ przetłumaczony przed Twoją zmianą zachowuje swoje tłumaczenie, a conntrack -L pokaże go długo po tym, jak polityka routingu poszła dalej. To nieaktualny stan, ale czyszczenie tras go nie dotknie.

Kontrola trzecia: czy stan jest w routingu, czy nad nim?

Przeczytaj bieżące wyszukiwanie, zanim przeczytasz cokolwiek innego: ip route get dla celu, potem to samo polecenie z from i adresem źródłowym, potem ip rule show. Jeśli te trzy zgadzają się z Twoim zamiarem, routing nie jest warstwą do naprawy, a nieaktualna obserwacja przyszła skądinąd.

Trzej typowi podejrzani siedzą nad routingiem. Menedżer sieci może ponownie zainstalować trasę z zapisanego profilu kilka sekund po tym, jak ją usuniesz, więc Twoja zmiana wygląda na cofniętą; sprawdź nmcli connection show --active i stan jednostki, zanim znów edytujesz tabelę. Pamięć podręczna resolvera zwraca stary adres, co wygląda na awarię routingu, dopóki nie zapytasz o tę samą nazwę narzędziem omijającym pamięć podręczną. Pula połączeń aplikacji trzyma działający socket do starego celu i nigdy nie prosi jądra o nową decyzję.

Co pozwalają Ci wywnioskować trzy odpowiedzi

Złóż odpowiedzi razem, a naprawa zwykle sama się wypowiada. Nowy przepływ, który wybiera złą ścieżkę na platformie bez pamięci podręcznej tras, oznacza, że polityka jest naprawdę błędna, więc przeczytaj reguły i tabelę zainstalowaną przez tunel. Nowy przepływ, który wybiera właściwą ścieżkę, podczas gdy stara sesja stoi, oznacza, że problemem jest aplikacja lub socket. Właściwe trasy z zepsutą obserwacją w obu przypadkach oznaczają, że stan jest nad routingiem.

Oprzyj się ogólnemu odświeżeniu. Restart stosu sieciowego lub usunięcie każdej trasy na maszynie, której trasą domyślną jest tunel, może odciąć dokładnie to połączenie, którego używasz do naprawy, i niszczy dowód, który powiedziałby, która warstwa zawiodła.

Jeśli naprawdę musisz coś wyczyścić, wyczyść najmniejszą rzecz pasującą do diagnozy: sockety jednego procesu, jeden wpis conntrack, pamięć podręczną resolvera. Potem powtórz ten sam test nowego przepływu i zapisz, co się zmieniło.

Trzymaj trzy stany osobno w swoich notatkach

Zapisana konfiguracja, bieżące wyszukiwanie i obserwowany przepływ to trzy różne fakty, a zlewanie ich w „pamięć podręczną” jest tym, co utrudnia odtworzenie usterki. Zapisz profil lub jednostkę, do której należy trasa, wyjście ip route get oraz źródło i cel rzeczywistego połączenia.

Zapisz obok platformę i wersję klienta, bo poprawka czyszcząca pamięć podręczną miejsc docelowych Windows nie jest poprawką dotyczącą hosta Linuksa, a procedura skopiowana między nimi uczy złej lekcji. Gdy przekażesz problem komuś innemu, te trzy linijki pozwolą mu odtworzyć stan awarii zamiast zgadywać.