Порт 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

Калі сокет ёсць, а кліент усё яшчэ не працуе, рэшта праблемы ніжэй па плыні, і памылка прывязвання ўжо гісторыя. Гэтае размежаванне і ёсць сутнасць таго, каб спачатку прачытаць дакладнае паведамленне: адна памылка, адзін узровень, адзін уладальнік. Чытайце так, і наступны сімптом пачнецца з вядомага стану, а не з здагадкі.