Ці хавае кэш маршрутаў 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 і стан модуля, перш чым зноў правіць табліцу. Кэш рэзалвера вяртае стары адрас, што выглядае як збой маршрутызацыі, пакуль вы не запытаеце тое ж імя інструментам, які абыходзіць кэш. Пул злучэнняў праграмы трымае працоўны сокет да старога прызначэння і ніколі не просіць ядро новага рашэння.

Што дазваляюць зрабіць тры адказы

Збярыце адказы разам, і рамонт звычайна сам сябе вызначае. Калі свежы паток ідзе няправільным шляхам на платформе без кэша маршрутаў, гэта значыць, што палітыка сапраўды няправільная, таму прачытайце правілы і табліцу, якую ўсталяваў тунэль. Калі свежы паток ідзе правільным шляхам, а стары сеанс захрасае, праблема ў праграме або сокеце. Правільныя маршруты з сапсаваным назіраннем у абодвух выпадках азначаюць, што стан над маршрутызацыяй.

Супраціўляйцеся ўніверсальнаму абнаўленню. Перазапуск сеткавага стэка або выдаленне ўсіх маршрутаў на машыне, чый маршрут па змаўчанні — тунэль, можа абарваць менавіта тое злучэнне, якое вы выкарыстоўваеце для выпраўлення, і знішчае доказы, якія сказалі б, які ўзровень зламаўся.

Калі вам усё ж трэба нешта ачысціць, ачышчайце найменшае, што адпавядае дыягназу: сокеты аднаго працэсу, адзін запіс conntrack, кэш рэзалвера. Затым паўтарыце той жа тэст свежага патоку і запішыце, што змянілася.

Трымайце тры станы асобна ў сваіх нататках

Захаваная канфігурацыя, бягучы пошук і назіраны паток — гэта тры розныя факты, і звядзенне іх у «кэш» — гэта тое, што робіць збой цяжка ўзнаўляльным. Запішыце профіль або модуль, якому належыць маршрут, вывад ip route get і крыніцу і прызначэнне фактычнага злучэння.

Запішыце побач платформу і версію кліента, бо выпраўленне, якое ачышчае кэш прызначэнняў Windows, не падыходзіць для хоста Linux, а працэдура, скапіяваная паміж імі, вучыць няправільнаму ўроку. Калі вы перадаеце праблему камусьці іншаму, гэтыя тры радкі дазволяць ім узнавіць збойны стан, а не здагадвацца.