Дали VPN кешот на рути ја крие вашата промена? Проверете три работи

Празнењето на кешот на рути е првиот инстинкт кога промената не стапува на сила, а на современ Linux тоа е залуден труд: глобалниот IPv4 кеш на рути беше отстранет пред години, па ip route show cache не печати ништо и нема што да се исчисти. Состојбата што ве измамува живее еден слој повисоко: во socket, NAT мапирање, resolver или мрежен менаџер што повторно го применил стариот профил. Три прашања ги раздвојуваат тие случаи: дали погрешниот пат доаѓа од нов тек или од стара врска, дали вашата платформа воопшто кешира рути, и дали состојбата е во рутирањето или над него. Одговорете им пред да ресетирате интерфејс.

Проверка прва: дали стариот пат доаѓа од нов тек?

Воспоставената врска ја задржува рутата со која е создадена. Затоа SSH сесијата преку тунелот преживува промена на табелата за рутирање, додека новата сесија веднаш го презема новиот пат, и затоа „промената не направи ништо“ често значи „стариот socket и понатаму го држи“. Тестирајте со нов процес, а не со прозорецот што веќе ви е отворен.

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

Последната команда ја печати адресата што новата врска навистина ја достигнала, и тоа е најевтиниот начин да се види вистинскиот пат без доверба во прозорец за состојба. Споредете ја со изворната адреса што namespace или интерфејсот требаше да ја користат.

Ако нов тек го земе правилниот пат, а стариот не се опорави, престанете да гледате во рутирањето. Рутата беше правилна; сесијата беше стара.

Проверка втора: дали вашата платформа воопшто држи кеш на рути?

На Linux одговорот е не, во смисла што го мислат повеќето водичи. Нема глобален кеш на одредишта што треба да се отфрли, а записот на ниво на socket што држи избрана рута се ослободува заедно со socket. Делот за кеш во прирачникот за ip-route опишува историско однесување, а не нешто што можете да го испразните на тековното јадро.

Другите платформи се разликуваат, и токму тука копирањето совети тргнува наопаку. Windows држи кеш на одредишта што можете да го исчистите со netsh interface ip delete destinationcache. BSD и macOS прикажуваат пребарувања по одредиште преку route -n get, и нивните кешеви истекуваат по сопствен распоред. Команда што работи на една од нив на Linux не прави ништо, затоа истиот поправка изгледа неуспешна за половината од луѓето што ја пробуваат.

NAT или conntrack табела не е кеш на рути, иако го произведува истиот симптом. Текот што беше преведен пред вашата промена го задржува својот превод, и conntrack -L ќе го покаже долго откако политиката за рутирање отиде понатаму. Тоа е застарена состојба, но чистењето рути нема да ја допре.

Проверка трета: дали состојбата е во рутирањето или над него?

Прочитајте го тековното пребарување пред што било друго: ip route get за одредиштето, потоа истата команда со from и изворната адреса, потоа ip rule show. Ако овие три се согласуваат со вашата намера, рутирањето не е слојот што треба да се поправи, и застареното набљудување дојде од друго место.

Три вообичаени осомничени седат над рутирањето. Мрежен менаџер може повторно да инсталира рута од зачуван профил секунди откако ќе ја избришете, па вашата промена изгледа како да се враќа; проверете nmcli connection show --active и состојбата на единицата пред повторно да ја уредувате табелата. Кешот на resolver враќа стара адреса, што изгледа како неуспех на рутирањето додека истото име не го прашате со алатка што го обиколува кешот. Базенот на врски на апликација држи работен socket до старото одредиште и никогаш не бара ново решение од јадрото.

Што ви дозволуваат да заклучите трите одговори

Соберете ги одговорите и поправката обично сама се изразува. Нов тек што го зема погрешниот пат на платформа без кеш на рути значи дека политиката е навистина погрешна, затоа прочитајте ги правилата и табелата што ги инсталираше тунелот. Нов тек што го зема правилниот пат додека старата сесија заглавува значи дека проблемот е апликацијата или socket. Правилни рути со расипано набљудување во двата случаи значат дека состојбата е над рутирањето.

Спротивставете се на општото освежување. Рестартирањето на мрежниот стек или бришењето на секоја рута на машина чија што стандардна рута е тунелот може да ја пресече токму врската што ја користите за да го поправите, и ги уништува доказите што ќе кажеа кој слој откажа.

Ако навистина мора да се исчисти нешто, исчистете ја најмалата работа што одговара на дијагнозата: socket-ите на еден процес, еден conntrack запис, кешот на resolver. Потоа повторете го истиот тест со нов тек и запишете што се промени.

Држете ги трите состојби одделно во вашите белешки

Зачуваната конфигурација, тековното пребарување и набљудуваниот тек се три различни факти, а нивното спојување во „кешот“ е она што го прави дефектот тешко репродуклив. Запишете го профилот или единицата што ја поседува рутата, излезот на ip route get, и изворот и одредиштето на вистинската врска.

Запишете до нив платформата и верзијата на клиентот, зашто поправка што чисти Windows кеш на одредишта не е поправка применлива на Linux домаќин, а постапка копирана меѓу двете учи погрешна лекција. Кога ќе му го предадете проблемот на некој друг, тие три реда му овозможуваат да ја репродуцира состојбата на дефект наместо да погодува.