Крие ли кешът на маршрутите на VPN промяната ви? Проверете три неща

Изчистването на кеша на маршрутите е първият инстинкт, когато промяна не влиза в сила, а на съвременния Linux това е напразно усилие: глобалният кеш на IPv4 маршрути бе премахнат преди години, така че ip route show cache не отпечатва нищо и няма какво да се изчисти. Състоянието, което ви заблуждава, живее едно ниво по-горе: в сокет, NAT съпоставяне, резолвер или мрежов мениджър, който е приложил отново стария профил. Три въпроса разделят тези случаи: идва ли грешният път от нов поток или от стара връзка, кешира ли платформата ви маршрути изобщо и дали състоянието е в маршрутизацията или над нея. Отговорете им, преди да нулирате интерфейс.

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

Установената връзка запазва маршрута, с който е създадена. Затова SSH сесия през тунела оцелява при промяна на таблицата с маршрути, докато нова сесия веднага поема новия път, и затова „промяната не направи нищо“ често означава „старият сокет още я държи“. Тествайте с нов процес, а не с прозореца, който вече имате отворен.

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 отговорът е не, в смисъла, който повечето ръководства влагат. Няма глобален кеш на дестинации, който да бъде изхвърлен, а записът на ниво сокет, който пази избран маршрут, се освобождава заедно със сокета. Разделът за кеша в ръководството за 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 и състоянието на unit-а, преди да редактирате таблицата отново. Кешът на резолвера връща стар адрес, което изглежда като отказ на маршрутизацията, докато не попитате същото име с инструмент, който заобикаля кеша. Пулът от връзки на приложението пази работещ сокет към старата дестинация и никога не пита ядрото за ново решение.

Какво ви позволяват да заключите трите отговора

Съберете отговорите и поправката обикновено се самоизяснява. Нов поток, който поема грешния път на платформа без кеш на маршрутите, означава, че политиката наистина е грешна, затова прочетете правилата и таблицата, която тунелът е инсталирал. Нов поток, който поема правилния път, докато старата сесия засяда, означава, че проблемът е в приложението или сокета. Правилни маршрути с повредено наблюдение и в двата случая означават, че състоянието е над маршрутизацията.

Устоявайте на общото обновяване. Рестартирането на мрежовия стек или изтриването на всеки маршрут на машина, чийто маршрут по подразбиране е тунелът, може да прекъсне точно връзката, която използвате, за да я поправите, и унищожава доказателствата, които биха казали кой слой се е провалил.

Ако все пак трябва да изчистите нещо, изчистете най-малкото, което отговаря на диагнозата: сокетите на един процес, един conntrack запис, кеша на резолвера. После повторете същия тест с нов поток и запишете какво се е променило.

Дръжте трите състояния отделно в бележките си

Запазената конфигурация, текущото търсене и наблюдаваният поток са три различни факта, а свиването им в „кеша“ е това, което прави дефекта труден за възпроизвеждане. Запишете профила или unit-а, който притежава маршрута, изхода на ip route get и източника и дестинацията на действителната връзка.

Запишете платформата и версията на клиента до тях, защото поправка, която изчиства кеша на дестинации на Windows, не е поправка, приложима към Linux хост, а процедура, копирана между двете, преподава грешния урок. Когато предадете проблема на някой друг, тези три реда му позволяват да възпроизведе отказалото състояние, вместо да гадае.