Два служебных адреса на одном клиенте OpenVPN: iroute и lo

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

Псевдоним локальный, владение удалённое

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

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

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

Добавьте адрес на клиенте постоянно

Поместите служебный адрес на loopback с префиксом хоста, чтобы хост считал его локальным вводом, а не подсетью, до которой нужно добраться. ip address add 10.66.0.10/32 dev lo делает это для одного адреса, а повтор команды для второго адреса моделирует две службы.

Запустите это как разовый тест, затем перенесите в то, что владеет сетевой конфигурацией хоста, потому что добавление во время работы исчезает при перезагрузке, а дубликаты накапливаются между переподключениями. Модуль systemd, упорядоченный после сети, — один вариант, а сетевой менеджер дистрибутива — другой. Что бы вы ни выбрали, адрес должен существовать до того, как приложение привяжется, иначе служба поднимется на неверном сокете. Проверьте с помощью ip address show dev lo после перезагрузки, а не после ручной команды.

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

Затребуйте его в файле CCD, который концентратор действительно читает

На сервере объявление владения попадает в файл отдельного клиента, выбираемый аутентифицированным общим именем, внутри каталога, указанного в client-config-dir. Строка — iroute 10.66.0.10 255.255.255.255, по одной на адрес, и она сообщает серверу, какой партнёр должен получать трафик для этого назначения.

Две детали ломают это молча. Имя файла должно совпадать с именем, которое сервер действительно использует, а оно отличается, когда задействован username-as-common-name. И iroute действует только в режиме TUN с настроенным каталогом конфигурации клиента, поэтому та же строка ничего не делает в мостовом развёртывании. Добавляйте строки в существующий файл, а не заменяйте его, так как он может уже нести фиксированный адрес или параметры push. Справочник OpenVPN 2.6 документирует и каталог, и директиву владения.

Собственному ядру концентратора тоже нужен путь к этим назначениям, чтобы локально созданный трафик попадал в процесс туннеля. route 10.66.0.10 255.255.255.255 в конфигурации сервера покрывает трафик, который порождает сам сервер, а другим клиентам нужен push "route 10.66.0.10 255.255.255.255", чтобы узнать назначение самостоятельно.

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

Проверьте политику ввода и обратный путь

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

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

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

Тестируйте адреса и владение отдельно

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

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