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

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

Начните с вопроса, для чего нужен второй туннель

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

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

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

Посмотрите на пулы раньше маршрутов

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

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

Два семейства адресов означают два круга этой проверки. Пулы IPv6 сталкиваются так же тихо, как IPv4.

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

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

systemctl cat [email protected]
ip -4 addr show

Затем решите, кто устанавливает маршруты, — это вопрос политики, а не синтаксиса.

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

Проверьте каждый туннель, затем остановите один

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

ip rule show
ip route get 203.0.113.9

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

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