Скрывает ли кэш маршрутов 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, а процедура, скопированная между ними, учит неверному уроку. Когда вы передаёте проблему кому-то другому, эти три строки позволяют воспроизвести сбойное состояние вместо догадок.