OpenVPN redirect-gateway: что каждый флаг делает с маршрутами

Подключитесь с redirect-gateway в профиле, и маршрут по умолчанию вашей машины может исчезнуть, разделиться на два или остаться ровно там, где был, в зависимости от флагов, которые никто не читает дважды. Параметр меняет только состояние маршрутизации и ничего больше, поэтому единственное достоверное доказательство того, что он сделал, — таблица, которую клиент установил после этого. Далее следуют таблица после подключения, маршрут, который поддерживает жизнь самого туннеля, и трафик IPv6, который директива никогда не обещает покрыть. Каждый шаг — команда, которую можно выполнить на клиенте, пока туннель поднят.

Что каждый флаг делает с маршрутом по умолчанию

Без единого флага параметр удаляет обычный маршрут по умолчанию и ставит на его место туннель, поэтому старый шлюз исчезает из таблицы, пока соединение активно. Добавьте def1, и этот маршрут по умолчанию остаётся в списке, а работу выполняют два более узких маршрута. Добавьте bypass-dhcp, и маршрут DHCP тоже выживает, что важно в сети, где клиенту всё ещё нужно достучаться до локального DHCP-сервера. Список флагов на странице руководства OpenVPN 2.6 достаточно короток, чтобы прочитать его один раз, и каждая запись меняет то, какие маршруты окажутся в таблице.

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

def1 побеждает за счёт точности, не трогая ваш маршрут по умолчанию

Два половинных маршрута по умолчанию вместе покрывают пространство IPv4, 0.0.0.0/1 и 128.0.0.0/1. Каждый из них точнее, чем 0.0.0.0/0, поэтому поиск предпочитает их, а настоящий маршрут по умолчанию остаётся в таблице для всего, что просит наименее точное совпадение.

Читайте таблицу, а не профиль, потому что только таблица показывает, в каком из этих случаев вы находитесь. Двух строк достаточно, чтобы их различить:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

Держите конечную точку туннеля доступной

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

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

ip route get 198.51.100.20

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

Трафик IPv6 продолжает использовать собственную таблицу

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

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

ip -6 route show default
ip -6 route get 2001:db8::10

Докажите, какой интерфейс использует приложение

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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