MULTI: неверный адрес источника от клиента: чей это был адрес?

Журнал сервера печатает MULTI: bad source address from client, отбрасывает пакет, а сеанс остаётся подключённым. Такое сочетание сбивает с толку тех, кто читает сообщение как неудачную аутентификацию. Это не так: клиент прошёл аутентификацию, а пришедший пакет нёс внутренний адрес источника, который сервер не смог связать с этим экземпляром клиента. Проверка происходит до доставки, поэтому туннель выглядит здоровым, хотя ничего полезного через него не проходит.

Что сервер сравнивает перед доставкой

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

Обычная доставка через интерфейс туннеля не происходит никогда.

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

Три источника несовпадающего внутреннего адреса

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

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

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

LAN за клиентом и iroute

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

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

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Убедитесь, что действующая личность совпадает с именем файла, так как несовпадение означает, что файл никогда не загружается, а симптом идентичен отсутствующей записи. Не добавляйте широкий iroute, чтобы заглушить предупреждение, так как это превращает неожиданный источник в разрешённый, не отвечая на вопрос, почему клиент его отправил. Руководство OpenVPN 2.6 документирует iroute, duplicate-cn и сопоставление личностей как отдельные средства контроля.

Одна и та же личность на двух машинах

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

Из-за этого неисправность выглядит прерывистой и появляется только когда оба устройства активны.

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

Докажите, что сопоставление изменилось

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

Повторите тот же поток и подтвердите три вещи: внутренний источник пакета, экземпляр клиента, с которым сервер его связывает, и поведение назначения после этого.

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