Два VPN-клиента одновременно: кто выигрывает маршрут по умолчанию?

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

Таблица маршрутов выбирает одного победителя

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

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

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

ip rule show

Windows решает это метриками

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

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

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

Два наблюдателя, два разных взгляда

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

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

DNS и IPv6 — это места, где цепочка протекает

DNS следует той настройке резолвера, которая побеждает, и это не обязательно путь, которым идут пакеты. Корпоративный резолвер, доступный через корпоративный туннель, согласуется с замыслом; локальный резолвер, доступный вне его, — нет, и он раскрывает имена, которые туннель должен был скрывать. IPv6 — вторая утечка: хост с двойным стеком продолжает использовать IPv6 к тем адресатам, которые туннель несёт только через IPv4. Проверяйте семейства отдельно, потому что туннель только для IPv4 ничего не говорит о маршрутах или резолверах IPv6.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

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