Vai VPN maršrutu kešatmiņa slēpj jūsu izmaiņas? Pārbaudiet trīs lietas

Maršrutu kešatmiņas tīrīšana ir pirmais instinkts, kad izmaiņas nestājas spēkā, un mūsdienu Linux tas ir veltīgs darbs: globālā IPv4 maršrutu kešatmiņa tika noņemta pirms gadiem, tāpēc ip route show cache neko neizdrukā un nav ko tīrīt. Stāvoklis, kas jūs maldina, dzīvo vienu slāni augstāk: socket, NAT kartējumā, resolverī vai tīkla pārvaldniekā, kas atkārtoti piemēroja veco profilu. Trīs jautājumi šos gadījumus atšķir: vai nepareizais ceļš nāk no jaunas plūsmas vai veca savienojuma, vai jūsu platforma vispār kešo maršrutus, un vai stāvoklis ir maršrutēšanā vai virs tās. Atbildiet uz tiem pirms saskarnes atiestatīšanas.

Pirmā pārbaude: vai vecais ceļš nāk no jaunas plūsmas?

Izveidots savienojums saglabā maršrutu, ar kuru tas tika izveidots. Tāpēc SSH sesija pa tuneli pārdzīvo maršrutu tabulas maiņu, kamēr jauna sesija uzreiz izvēlas jauno ceļu, un tāpēc „izmaiņas neko nedarīja“ bieži nozīmē „vecais socket joprojām to tur“. Pārbaudiet ar jaunu procesu, nevis ar logu, kas jau ir atvērts.

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

Pēdējā komanda izdrukā adresi, ko jaunais savienojums faktiski sasniedza, un tas ir lētākais veids, kā redzēt reālo ceļu, neuzticoties statusa logam. Salīdziniet to ar avota adresi, kas namespace vai saskarnei bija jāizmanto.

Ja jauna plūsma izvēlas pareizo ceļu un vecā neatjaunojas, pārtrauciet skatīties uz maršrutēšanu. Maršruts bija pareizs; sesija bija veca.

Otrā pārbaude: vai jūsu platforma vispār glabā maršrutu kešatmiņu?

Linux atbilde ir nē, tādā nozīmē, kādu domā lielākā daļa rokasgrāmatu. Nav globālas galamērķa kešatmiņas, ko izmest, un socket līmeņa ieraksts, kas glabā izvēlēto maršrutu, tiek atbrīvots kopā ar socket. ip-route rokasgrāmatas kešatmiņas sadaļa apraksta vēsturisku uzvedību, nevis kaut ko, ko varat iztīrīt pašreizējā kodolā.

Citas platformas atšķiras, un tieši šeit padomu kopēšana neizdodas. Windows glabā galamērķa kešatmiņu, ko varat notīrīt ar netsh interface ip delete destinationcache. BSD un macOS rāda meklējumus katram galamērķim, izmantojot route -n get, un viņu kešatmiņas beidzas pēc sava grafika. Komanda, kas darbojas vienā no tām, Linux nedara pilnīgi neko, tāpēc tas pats labojums šķiet neizdevies pusei to, kas to izmēģina.

NAT vai conntrack tabula nav maršrutu kešatmiņa, lai gan rada to pašu simptomu. Plūsma, kas tika tulkota pirms jūsu izmaiņām, saglabā savu tulkojumu, un conntrack -L to parādīs vēl ilgi pēc tam, kad maršrutēšanas politika ir pavirzījusies tālāk. Tas ir novecojis stāvoklis, bet maršrutu tīrīšana to neaizskars.

Trešā pārbaude: vai stāvoklis ir maršrutēšanā vai virs tās?

Izlasi pašreizējo meklējumu pirms jebko cita: ip route get galamērķim, pēc tam tā pati komanda ar from un avota adresi, pēc tam ip rule show. Ja šie trīs sakrīt ar jūsu nodomu, maršrutēšana nav labojamais slānis, un novecojušais novērojums nāca no citurienes.

Trīs ierasti aizdomās turamie sēž virs maršrutēšanas. Tīkla pārvaldnieks var atkārtoti instalēt maršrutu no saglabāta profila dažas sekundes pēc tam, kad to izdzēšat, tāpēc jūsu izmaiņas šķiet atgriežamies; pārbaudiet nmcli connection show --active un vienības stāvokli pirms tabulas atkārtotas rediģēšanas. Resolvera kešatmiņa atgriež vecu adresi, kas izskatās kā maršrutēšanas kļūda, līdz jūs pajautājat to pašu nosaukumu ar rīku, kas apiet kešatmiņu. Lietotnes savienojumu pūls tur darba socket uz veco galamērķi un nekad neprasa kodolam jaunu lēmumu.

Ko ļauj secināt trīs atbildes

Salieciet atbildes kopā, un labojums parasti pasaka pats sevi. Jauna plūsma, kas izvēlas nepareizo ceļu platformā bez maršrutu kešatmiņas, nozīmē, ka politika patiešām ir nepareiza, tāpēc izlasiet noteikumus un tabulu, ko tunelis instalēja. Jauna plūsma, kas izvēlas pareizo ceļu, kamēr vecā sesija iestrēgst, nozīmē, ka problēma ir lietotnē vai socket. Pareizi maršruti ar salauztu novērojumu abos gadījumos nozīmē, ka stāvoklis ir virs maršrutēšanas.

Pretojieties vispārīgajai atsvaidzināšanai. Tīkla steka restartēšana vai visu maršrutu dzēšana mašīnā, kuras noklusējuma maršruts ir tunelis, var pārtraukt tieši to savienojumu, ko izmantojat tā labošanai, un tas iznīcina pierādījumus, kas būtu pateikuši, kurš slānis neizdevās.

Ja tomēr kaut kas ir jāiztīra, iztīriet mazāko lietu, kas atbilst diagnozei: vienas lietotnes socketus, vienu conntrack ierakstu, resolvera kešatmiņu. Pēc tam atkārtojiet to pašu jaunās plūsmas testu un pierakstiet, kas mainījās.

Turiet trīs stāvokļus atsevišķi savos pierakstos

Saglabātā konfigurācija, pašreizējais meklējums un novērotā plūsma ir trīs dažādi fakti, un to saplūšana „kešatmiņā“ ir tas, kas padara kļūdu grūti reproducējamu. Pierakstiet profilu vai vienību, kam pieder maršruts, ip route get izvadi un īstā savienojuma avotu un galamērķi.

Blakus pierakstiet platformu un klienta versiju, jo labojums, kas notīra Windows galamērķa kešatmiņu, nav labojums, kas attiecas uz Linux resursdatoru, un procedūra, kas nokopēta starp abiem, māca nepareizo mācību. Kad nododat problēmu kādam citam, šīs trīs rindas ļauj viņam reproducēt bojāto stāvokli, nevis minēt.