Ваш старый маршрут по умолчанию намеренно переживает OpenVPN

Вы подключаете туннель, выполняете ip route, и исходный шлюз по умолчанию по-прежнему там. Следующая мысль — клиент не перехватил маршрут, поэтому вы вручную удаляете маршрут по умолчанию и полностью теряете связь. Эта запись должна остаться. С redirect-gateway def1 OpenVPN устанавливает два более конкретных маршрута, которые превосходят обычный маршрут по умолчанию, а не заменяют его. Старый шлюз остаётся и перестаёт нести трафик, который вы проверяли.

Что на самом деле делает def1

Флаг добавляет 0.0.0.0/1 и 128.0.0.0/1, оба указывают на туннель. 0.0.0.0/1 охватывает каждый адрес, первый октет которого от 0 до 127, а 128.0.0.0/1 — от 128 до 255, поэтому у каждого адресата IPv4 есть более конкретное совпадение, чем у старого маршрута по умолчанию. Какой маршрут победит, решает длина префикса, а не метрика.

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

Почему /1, а не /0

Маршрутизация выбирает самый длинный подходящий префикс, а не самую низкую метрику, поэтому /1 побеждает /0 независимо от того, что говорит метрика маршрута по умолчанию. Обе половины существуют потому, что один /1 покрывает лишь половину пространства; когда есть только 0.0.0.0/1, всё от 128.0.0.0 и выше по-прежнему следует старому маршруту по умолчанию, что даёт сбивающий с толку симптом: одни сайты работают, а другие нет.

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

Прочитайте настоящую таблицу маршрутизации

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Важно отношение: две конкретные половины над одним общим маршрутом по умолчанию. Строка старого шлюза остаётся, потому что ничто её не заменило.

Проверьте, какой маршрут действительно выбирает пакет

Более конкретные маршруты всё ещё могут победить: маршрут для частного диапазона, локальной подсети или собственный адрес сервера VPN длиннее, чем /1. Туннелю нужен внешний путь к своему серверу, и отправка этого соединения обратно в туннель сразу его сломает. В Linux спросите ядро вместо того, чтобы читать таблицу глазами: ip route get с интересующим вас адресатом выводит выбранный маршрут, интерфейс и источник. Если настроена маршрутизация по политикам, просмотрите и правила, потому что правило может выбрать другую таблицу до обращения к основной.

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

Чего def1 не покрывает

Две записи IPv4 ничего не говорят об IPv6: хост с подключением IPv6 продолжает использовать свой маршрут по умолчанию, пока что-то не перенаправит это семейство отдельно, поэтому в сети с двойным стеком часть трафика как будто обходит туннель. Другие клиенты и менеджеры сети реализуют маршрутизацию полного туннеля иначе, и их таблицы не совпадут. Описанное здесь поведение def1 относится к документированному флагу OpenVPN, а не к каждому VPN на машине.

Аварийный выключатель отвечает на другой вопрос: что делает машина, когда туннель падает. Приоритет маршрутов решает, куда идёт трафик, пока туннель поднят; он не решает, что потом делает межсетевой экран. Порядок работы: прочитайте таблицу, подтвердите, что обе половины существуют, выполните ip route get для сбойного адресата, проверьте правила политик и затем отдельно посмотрите на IPv6. Оставьте старый маршрут по умолчанию там, где он есть.