Да ли 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 домаћин, а поступак копиран између њих учи погрешну лекцију. Када проблем предате неком другом, та три реда му омогућавају да репродукује стање квара уместо да нагађа.