OpenVPN: local и адрес туннеля, два разных сокета

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

Ошибка привязки называет локальный адрес

Когда OpenVPN сообщает, что не может привязать локальный адрес, речь идёт о транспортном сокете: конечной точке UDP или TCP, которая несёт зашифрованное соединение к пиру.

Явная директива local просит демон привязать этот сокет к конкретному локальному адресу. Адрес должен существовать в сетевом пространстве имён, где работает процесс, и должен быть назначаемым в момент запуска клиента.

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

Что на самом деле выбирают local и remote

remote называет пира, с которым нужно связаться. local привязывает ближний конец того же сокета. nobind позволяет операционной системе выбрать и локальный адрес, и порт, поэтому клиенты за домашними маршрутизаторами обычно работают без обеих директив.

Ни одна из этих директив не имеет отношения к адресу внутри туннеля.

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

ip -brief address show
ip route get 203.0.113.10

Внутренний адрес приходит от сервера

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

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

Интерфейсы, которые нужно читать, тоже другие. Параметры ifconfig и конфигурация пула описывают внутреннюю сторону, а remote, local, proto и nobind описывают внешнюю. Разделение этих двух списков объясняет почти каждый запутанный пример, который вы найдёте на форуме. Именно поэтому руководство OpenVPN 2.6 описывает их в отдельных разделах.

Ловушка: полный туннель, который захватывает собственный транспорт

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

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

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

Привычка, которая предотвращает путаницу

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

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

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