Два VPN на одной машине Linux: проверяйте каждый отдельно, не смешивая результаты

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

Две зелёные лампочки — не сравнение

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

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

Закрепите ожидание до первого запуска

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

Обвязка резолвера заслуживает отдельной строки в этой записи, потому что именно это поле чаще всего лжёт. Файлы, привязанные к пространству имён, такие как /etc/netns/vpn-a/resolv.conf появляются по своим обычным путям, когда команда выполняется внутри пространства имён, как описывает справка iproute2 о пространствах имён, но настройка переключения службы имён и любой локальный резолвер, который она запускает, всё ещё могут утянуть запрос обратно на хост.

Один туннель за раз, другой отключён

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

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

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

Оба включены, затем по одному выключению

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

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

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

Что эта запись может и чего не может утверждать

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

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

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