Запустите один и тот же профиль сервера дважды, и второй процесс завершится ошибкой «адрес уже используется» для порта 1194. В обычном случае конфликт создал диагностический запуск, а исходный экземпляр по-прежнему прекрасно обслуживает клиентов. Эта история объясняет значительную часть таких отчётов, и её стоит распознать до того, как что-либо перезапускать. Это также самый дешёвый вариант решения.

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

Прочитайте точную ошибку связывания

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

Составьте опись сокета, а не порта

Номер порта — неполная опись. Конечная точка — это транспорт, семейство адресов, локальный адрес и порт, всё внутри одного сетевого пространства имён. UDP-прослушиватель и TCP-прослушиватель на одном номере — разные сокеты, а два процесса на одном номере в разных пространствах имён никогда не встречаются.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

Выясните, какой процесс им владеет

Числовые конечные точки плюс сведения о процессе идентифицируют владельца, когда ваши права это позволяют, и вам нужен именно владелец, а не имя программы. Два процесса OpenVPN могут запускать разные профили, и тот, что держит прослушиватель, может оказаться наименее очевидным.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

Один владелец или два спроектированных экземпляра

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

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

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

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

Проверьте связывание раньше всего остального

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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

Похожие статьи