Чи приховує кеш маршрутів VPN вашу зміну? Перевірте три речі

Очищення кешу маршрутів — перший інстинкт, коли зміна не набуває чинності, і на сучасному Linux це марна праця: глобальний кеш маршрутів IPv4 видалили роки тому, тож ip route show cache нічого не друкує і очищати нічого. Стан, який вас обманює, живе на рівень вище: у socket, NAT-зіставленні, резолвері або мережевому менеджері, який повторно застосував старий профіль. Три питання розділяють ці випадки: чи приходить неправильний шлях із нового потоку чи старого з'єднання, чи кешує ваша платформа маршрути взагалі, і чи стан у маршрутизації чи над нею. Дайте на них відповідь, перш ніж скидати інтерфейс.

Перевірка перша: чи приходить старий шлях із нового потоку?

Установлене з'єднання зберігає маршрут, з яким було створене. Тому 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 і стан unit перед повторним редагуванням таблиці. Кеш резолвера повертає стару адресу, що виглядає як збій маршрутизації, доки ви не запитаєте те саме ім'я інструментом, який обходить кеш. Пул з'єднань застосунку тримає робочий socket до старого призначення і ніколи не питає ядро про нове рішення.

Що дозволяють виснувати три відповіді

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

Опирайтеся загальному оновленню. Перезапуск мережевого стека або видалення кожного маршруту на машині, де маршрут за замовчуванням — тунель, може обірвати саме те з'єднання, яке ви використовуєте для виправлення, і знищує докази, які сказали б, який шар відмовив.

Якщо все ж треба щось очистити, очистьте найменше, що відповідає діагнозу: socket одного процесу, один запис conntrack, кеш резолвера. Потім повторіть той самий тест нового потоку і запишіть, що змінилося.

Тримайте три стани окремо у своїх нотатках

Збережена конфігурація, поточний пошук і спостережуваний потік — три різні факти, і злиття їх у «кеш» — це те, що робить збій важко відтворюваним. Запишіть профіль або unit, якому належить маршрут, вивід ip route get, а також джерело й призначення реального з'єднання.

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