Два туннеля OpenVPN на одном хосте Linux: кому принадлежит маршрут?

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

Начните с задачи, которую должен выполнить второй канал

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

Перекрывающиеся пулы ломаются раньше маршрутизации

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

Посмотрите и на локальную LAN. Домашняя сеть с номером 192.168.1.0/24, которую тоже открывает один туннель, создаёт ту же неоднозначность, а симптом — имя хоста, которое разрешается, пока соединение так и не устанавливается. Это выглядит как сбой разрешения имён, пока вы не напечатаете маршруты.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

Дайте каждому профилю свой юнит, а каждому префиксу — владельца

Каждый профиль получает собственное имя экземпляра и собственный файл конфигурации, поэтому экземпляр с именем office загружает office.conf, а экземпляр с именем lab — lab.conf. Подтвердите это сопоставление через менеджер служб, а не доверяя листингу каталога, поскольку drop-in может изменить, какой файл загружается. Ошибка в сопоставлении означает, что вы настраиваете профиль, который не работает.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

Метки удерживают ответы на том интерфейсе, откуда они пришли

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

Докажите изоляцию, остановив один канал

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

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

Верните остановленный профиль и повторите те же проверки. Когда туннель выживает только при первом запуске после перезагрузки, вы видите дефект жизненного цикла, а не проект маршрутизации.