Windows 11: несколько VPN-подключений одновременно — как не ловить конфликты

MAATRIX

Если на Windows 11 у вас одновременно активны два VPN-клиента — например, WireGuard для доступа к рабочей сети и OpenVPN для сервера в другой стране, — рано или поздно один из них начинает «глушить» другой: пропадает интернет, RDP отваливается, часть сайтов открывается, часть нет. Причина почти всегда одна: оба клиента пытаются стать основным шлюзом по умолчанию, и система маршрутизации путается, кому верить. Разбираемся, как это чинить руками — через метрики маршрутов и приоритет адаптеров, а не переустановкой клиентов в надежде, что «само пройдёт».

Почему два VPN одновременно — это конфликт по умолчанию

Windows строит сетевые решения на основе таблицы маршрутов. У каждого маршрута есть метрика — число, которое показывает его «стоимость»: чем меньше метрика, тем выше приоритет. Когда вы поднимаете один VPN, клиент обычно добавляет маршрут 0.0.0.0/0 (весь трафик) через свой туннель и назначает ему низкую метрику, чтобы перебить основной маршрут через физический адаптер. Это нормальное поведение для одиночного VPN.

Проблема начинается, когда вы поднимаете второй туннель тем же способом. Второй клиент тоже добавляет собственный 0.0.0.0/0 и тоже старается получить приоритет. В таблице маршрутов оказывается два конкурирующих маршрута в интернет, и Windows выбирает между ними по метрике интерфейса и метрике самого маршрута в сумме. Итог непредсказуем: либо весь трафик уходит в последний поднятый туннель (и первый становится бесполезным), либо система начинает «дёргаться» между ними при каждом обновлении DHCP-аренды или переподключении одного из клиентов.

Отдельная головная боль — DNS. Если оба клиента прописывают себе DNS-серверы, Windows опрашивает их в порядке, заданном приоритетом интерфейсов (Interface Metric), а не в порядке подключения. Это значит, что даже когда маршруты трафика настроены верно, разрешение имён может уходить не туда — отсюда классическая ситуация «пинг по IP работает, а по имени — нет».

Как посмотреть текущие маршруты и метрики

Прежде чем что-то менять, нужно увидеть, что происходит на самом деле. Базовая команда — route print в командной строке:

route print -4

Она покажет три блока: список интерфейсов с их индексами, таблицу активных маршрутов (Network Destination, Netmask, Gateway, Interface, Metric) и таблицу постоянных маршрутов (Persistent Routes). Ищите строки с 0.0.0.0 в качестве Network Destination и Netmask — если таких строк с ненулевым Gateway больше одной, у вас и есть тот самый конфликт.

Более наглядный способ — PowerShell:

Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Format-Table InterfaceAlias, NextHop, RouteMetric, ifMetric -AutoSize

Эта команда сразу выведет все маршруты по умолчанию с привязкой к имени адаптера. Обратите внимание: итоговый приоритет маршрута — это сумма RouteMetric (метрика самого маршрута) и ifMetric (метрика интерфейса, к которому он привязан). Побеждает меньшая сумма.

Чтобы посмотреть метрики самих интерфейсов отдельно:

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table InterfaceAlias, InterfaceMetric, ConnectionState, Dhcp -AutoSize

Если у вас включено автоматическое назначение метрик (по умолчанию так и есть), Windows сама расставляет значения на основе скорости адаптера и типа подключения — и именно это чаще всего сбивается, когда виртуальных адаптеров становится больше одного.

Приоритет сетевых адаптеров в Windows 11

Есть два независимых механизма приоритета, и их часто путают: порядок привязки адаптеров (Adapter Binding Order) и метрика IP-интерфейса (Interface Metric). Первый влияет на то, в каком порядке система перебирает адаптеры для служб, которые не завязаны жёстко на таблицу маршрутов; второй — на то, какой маршрут выигрывает при прочих равных условиях.

Порядок привязки меняется через классическую панель управления:

1. ncpa.cpl → Alt (чтобы показать меню) → Дополнительно → Дополнительные параметры.
2. Во вкладке Адаптеры и привязки перетащите нужный VPN-адаптер выше остальных стрелками справа.

Метрику интерфейса лучше выставлять вручную, отключив автоматику — это даёт предсказуемость, которой не хватает при двух активных туннелях:

Set-NetIPInterface -InterfaceAlias "WireGuard Tunnel" -InterfaceMetric 5
Set-NetIPInterface -InterfaceAlias "OpenVPN TAP-Windows Adapter V9" -InterfaceMetric 15
Set-NetIPInterface -InterfaceAlias "Ethernet" -InterfaceMetric 25

Логика простая: чем важнее, чтобы трафик по умолчанию шёл через конкретный туннель, тем ниже у него должна быть метрика. Физический адаптер оставляйте с самой высокой метрикой из тех, что участвуют в конкуренции за 0.0.0.0/0, — тогда при падении обоих VPN интернет не пропадёт совсем, а откатится на обычное подключение.

Проверить результат:

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric

Split-tunnel вместо борьбы за default gateway

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

Для OpenVPN это делается на уровне конфига клиента — убираете директиву redirect-gateway def1 (которая как раз и захватывает весь трафик) и вместо неё прописываете конкретные маршруты:

route 10.20.0.0 255.255.0.0
route 192.168.50.0 255.255.255.0

Так клиент поднимет туннель и добавит маршруты только к нужным подсетям, не трогая маршрут по умолчанию.

Для WireGuard то же самое регулируется параметром AllowedIPs в секции [Peer] конфига. Значение 0.0.0.0/0 означает full-tunnel и претендует на весь трафик; если нужен split-tunnel, укажите только реальные подсети сервера:

[Peer]
PublicKey = <ключ_сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.0.0/24, 172.16.0.0/16

Если же вам действительно нужно, чтобы весь трафик шёл именно через один из двух VPN (например, второй туннель — просто для доступа к внутренним ресурсам), то full-tunnel можно оставить только у одного клиента, а второй перевести в split-tunnel режим. Тогда конкуренции за default gateway не возникает в принципе — и настройка метрик из предыдущего раздела становится подстраховкой, а не единственным способом разрулить конфликт.

Постоянные (persistent) маршруты для split-tunnel сценариев, которые должны переживать перезагрузку, добавляются так:

route -p add 10.20.0.0 mask 255.255.0.0 192.168.99.1 metric 5 if 12

где if 12 — индекс интерфейса из вывода route print, а 192.168.99.1 — шлюз внутри туннеля.

Практический сценарий: WireGuard плюс OpenVPN одновременно

Разберём конкретный случай: WireGuard используется для стабильного доступа к рабочей инфраструктуре (full-tunnel не нужен, только конкретные подсети), а OpenVPN — для выхода в интернет через сервер в другой юрисдикции (нужен полноценный full-tunnel).

Порядок действий:

1. В конфиге WireGuard выставляете AllowedIPs только на нужные подсети — этот туннель не претендует на 0.0.0.0/0.
2. В конфиге OpenVPN оставляете redirect-gateway def1 — этот туннель забирает весь остальной трафик.
3. После поднятия обоих проверяете таблицу маршрутов: у WireGuard в ней должны быть только явные подсети, у OpenVPN — единственный маршрут 0.0.0.0/0.
4. Если параллельно с этим настроен доступ по RDP через один из туннелей, проверьте отдельно, что нужный маршрут не перебивается метрикой физического адаптера — это частая причина, когда RDP через WireGuard вдруг перестаёт открываться после поднятия второго VPN.
5. Явно выставляете метрики интерфейсов PowerShell-командами из раздела выше, даже если маршруты уже разведены логически — это исключает ситуацию, когда Windows после сна или переподключения адаптера пересчитает автоматические метрики и снова столкнёт туннели.

Если вместо WireGuard или OpenVPN на клиентской машине вы используете штатный клиент Windows (например, IKEv2-подключение к серверу на базе RRAS), логика та же самая: настройка RRAS с IKEv2 со стороны сервера не отменяет необходимости развести маршруты на клиенте, если параллельно поднят ещё один туннель.

Диагностика: что проверять, если что-то не работает

Когда после настройки метрик и AllowedIPs всё равно есть проблемы, порядок диагностики такой:

1. Убедитесь, что маршрут по умолчанию только один (или ровно тот, который вы ожидаете):

Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object (RouteMetric+ifMetric) -Descending

2. Проверьте DNS-серверы по интерфейсам — Windows использует их в порядке метрик, а не в порядке подключения VPN:

Get-DnsClientServerAddress -AddressFamily IPv4

3. Проверьте, откуда реально уходит конкретный пакет, вместо гаданий по таблице:

tracert -d 8.8.8.8

Если трасса с первого прыжка идёт не туда, куда вы рассчитывали, — виновата метрика или порядок адаптеров, а не сам VPN-клиент.

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

Test-NetConnection -ComputerName 10.20.0.1 -Port 3389

5. Если один из клиентов — WireGuard, посмотрите его собственную статистику, чтобы отличить проблему на уровне туннеля от проблемы маршрутизации: пустой latest handshake или нулевой transfer при верно настроенных маршрутах — это уже отдельная история про сам туннель, а не про приоритет адаптеров (симптомы разобраны в статье про WireGuard, у которого есть handshake, но нет трафика).

Частая ошибка на этом этапе — чинить маршруты, вместо того чтобы сначала перезапустить один из клиентов. Оба VPN-клиента при подключении пишут маршруты в таблицу, но не всегда аккуратно чистят их при отключении, особенно после аварийного разрыва связи. Если таблица маршрутов выглядит «мусорной» (дублирующиеся или битые записи), проще отключить оба клиента, вручную удалить оставшиеся маршруты (route delete 0.0.0.0), и поднять туннели заново в нужном порядке.

Частые вопросы