Порт 1194 уже зайнятий: кому належить цей сокет OpenVPN?

Запустіть той самий профіль сервера двічі, і другий процес завершиться помилкою «адреса вже використовується» для порту 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

Якщо сокет присутній, а клієнт досі не працює, решта проблеми нижче за потоком, і помилка зв’язування вже історія. Саме це розділення і є весь сенс спершу прочитати точне повідомлення: одна помилка, один рівень, один власник. Читайте так, і наступний симптом почнеться з відомого стану, а не з здогаду.