Два VPN-клиента на одном компьютере: что конфликтует и что работает

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

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

Шаг 1: выясните, какой клиент владеет выходом

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

ip route get 1.1.1.1
ip route show default
route print

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

Остановитесь, если оба клиента требуют один и тот же префикс с одинаковой метрикой. Ядро выберет один, а второй будет выглядеть подключённым, ничего не передавая.

Шаг 2: проверьте резолвер и перекрывающиеся префиксы

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

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

Остановитесь здесь, если префиксы перекрываются. Всё дальнейшее в этом списке предполагает, что они не перекрываются.

Шаг 3: выберите схему разделения, которая держится

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Пространство имён даёт такое же разделение, как виртуальная машина, без второй операционной системы, но у него есть шероховатости: устройство туннеля нужно перенести внутрь, а приложение запустить там же. Отдельное физическое устройство часто оказывается наименее неожиданным вариантом для личного VPN рядом с управляемым рабочим клиентом. Вложение одного туннеля в другой не является схемой разделения; внутренняя конечная точка должна оставаться доступной через внешний туннель, а такая схема добавляет проблемы с MTU и задержкой.

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

Шаг 4: проверьте обе сети из одной сессии

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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

Похожие статьи