route-gateway — это не redirect-gateway: что на самом деле меняется

Туннель поднимается, частная подсеть отвечает, а обычный просмотр по-прежнему уходит в VPN, хотя кто-то удалил строку шлюза из профиля. Это сочетание — отпечаток правки не той директивы. Удалённое давало клиенту следующий хоп для маршрутов, которые он устанавливает; то, что продолжало перехватывать трафик, пришло из другого места и было протолкнуто сервером. Покрытие и следующий хоп — разные задачи, и только одна из них решает, используют ли публичные назначения туннель.

Удалённая строка была следующим хопом, а не переключателем политики

Каждому маршруту, который устанавливает клиент, нужен адрес шлюза, на который указывать, и директива шлюза служит источником этого адреса, когда маршрут сам его не называет. Удалите её, и этим маршрутам не к чему прикрепиться, поэтому они либо не установятся, либо попадут на путь, который никуда не ведёт. Частная подсеть — именно то, что несла такая маршрут.

Тем временем у выжившего поведения другой автор: опция перенаправления в протолкнутом блоке, которая переносит обычный исходящий трафик в туннель согласно своим флагам. Удаление шлюза не отключает и не ослабляет её. Результат — худшее из обоих состояний: публичный трафик по-прежнему перехватывается, а частное назначение, оправдывавшее туннель, теперь недоступно. Поэтому и вторая правка, сделанная в том же духе, тоже ничего не меняет.

Четыре рычага, четыре разные задачи

В этом обсуждении четыре директивы цитируются как взаимозаменяемые, и только одна из них управляет покрытием, то есть тем, какие назначения вообще идут через туннель. Вторая задаёт следующий хоп, который используют маршруты, третья устанавливает один префикс, а четвёртая выбрасывает всё, что протолкнул сервер, включая частные маршруты, нужные развёртыванию. Таблица упорядочивает их по тому, что администратор пытается изменить, а не по имени, потому что путаницу вызывают именно имена. Рассматривайте их как четыре отдельных решения и выберите то, которое действительно хотите отменить.

На практике все четыре часто приходят в одном протолкнутом блоке, строка за строкой, из-за чего кажутся частями одной настройки. Это не так, и справочник OpenVPN документирует их как разные механизмы именно поэтому. Выяснить, какое решение вы отменяете, — это работа; правка — одна строка.

Фильтруйте протолкнутую строку, сохраняйте следующий хоп

Если покрытие, против которого вы возражаете, приходит как протолкнутая опция, узкий ответ — игнорировать эту опцию по имени и оставить остальную часть протолкнутого блока нетронутой. Записанный как фильтр, он выглядит как строка ниже, и его место в профиле затронутого клиента, а не в конфигурации сервера.

pull-filter ignore "redirect-gateway"

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

Читайте поиск, а не таблицу

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

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Вариант def1 стоит знать, потому что он оставляет старую запись по умолчанию видимой, пока пара половинных записей выигрывает поиск. Поэтому строка 0.0.0.0/0 в выводе сама по себе ничего не доказывает. Поиск отвечает на вопрос, на который список только кажется отвечающим.

DNS, IPv6 и частный маршрут должны по-прежнему работать

Отказ от одного перенаправления IPv4 ничего не говорит о резолвере, поэтому протолкнутая опция DNS может продолжать отправлять запросы в туннель, пока маршруты выглядят правильными. Значение по умолчанию IPv6 может сделать то же самое для семейства адресов, которого проверка IPv4 никогда не касалась. Обоим нужно явное решение вместо предположения. Затем убедитесь, что частная служба всё ещё отвечает, потому что разделённый туннель, потерявший свой частный маршрут, — это не разделённый туннель, а сломанный.

Один более широкий инструмент заслуживает предупреждения: route-nopull отбрасывает каждый протолкнутый маршрут и каждую протолкнутую опцию DNS, что непременно останавливает полный туннель и столь же непременно ломает частные маршруты, от которых зависит развёртывание, так что это куда больший молот, чем фильтр по имени, нацеленный на одну опцию. Проверяйте частное назначение, публичное назначение и резолвер после любого изменения, а завершённое рукопожатие считайте доказательством ничего, кроме самого рукопожатия.