Два клиента VPN, одна таблица маршрутизации: кто получает маршрут по умолчанию

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

Конфликт живёт в таблице маршрутизации

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

Клиенты — редакторы одной общей таблицы. Знание того, какое изменение было последним, объясняет почти каждый симптом.

Прочитайте, какой туннель владеет текущим путём

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

ip route get 10.20.0.5
route print -4

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

Остановите второй клиент от притязаний на всё

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

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull игнорирует каждый навязанный маршрут, а pull-filter ignore "redirect-gateway" отбрасывает только директиву маршрута по умолчанию и сохраняет навязанные DNS и другие параметры. Выбирайте между ними по тому, сколько конфигурации сервера вам ещё нужно, затем добавьте конкретные префиксы, которые требуются второй сети. Помните про DNS, потому что резолвер, навязанный туннелем, который не несёт запросы, ничего не возвращает. Проверьте один известный хост в каждой сети и подтвердите адрес источника, который видит удалённая сторона.

Перекрывающиеся подсети нельзя обойти

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

Разделите и две цели: добраться до обеих сетей — задача маршрутизации, а сцепка туннелей ради приватности — другой проект с дополнительным оператором на пути. Не используйте одно, чтобы решить другое.