Что bypass-dhcp на самом деле добавляет к схеме маршрутов OpenVPN

Профиль с redirect-gateway def1 bypass-dhcp сочетает замену маршрута IPv4 по умолчанию с одним узким исключением. Люди читают последнее слово и ждут общего решения для мобильных подключений, а затем проводят полдня с теорией DHCP, которую этот флаг никогда не поддерживал. Каждая часть делает одно дело, и исключение гораздо меньше своей репутации.

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

Два флага, две несвязанные задачи

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

bypass-dhcp отдельный и вовсе не затрагивает маршрут по умолчанию. Руководство OpenVPN 2.6 описывает его как добавление прямого маршрута к серверу DHCP, который не находится в локальной подсети, так что трафик аренды выходит за пределы туннеля, и отмечает, что такое поведение реализовано на клиентах Windows и может быть недоступно в других местах.

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

На что на самом деле распространяется исключение

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

Проверьте, что клиент действительно установил

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

Держите маршрут к конечной точке VPN одновременно работоспособным. Это исключение для конечной точки — другое требование, чем исключение DHCP, и без него туннель может захватить транспорт, который его поддерживает.

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

Остаток пути не в этом флаге

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

Разрешение имён и IPv6 каждому нужна своя политика. Замена IPv4 ни направляет резолвер к серверу на стороне туннеля, ни создаёт покрытие IPv6, а клиент, который перенаправляет только v4, оставляет путь v6 нетронутым.

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