Porta 1194 është tashmë në përdorim: kujt i përket ai socket i OpenVPN?

Nisni të njëjtin profil serveri dy herë, dhe procesi i dytë përfundon me një gabim se adresa është tashmë në përdorim për portën 1194. Në rastin e zakonshëm, nisja diagnostike krijoi konfliktin, dhe instanca origjinale vazhdon t'u shërbejë klientëve në mënyrë të përsosur. Kjo histori shpjegon një pjesë të madhe të këtyre raporteve, dhe ia vlen ta njohësh përpara se të rinisësh çdo gjë. Është gjithashtu versioni më i lirë për t'u zgjidhur.

Gabimi përshkruan një lidhje lokale dhe asgjë përtej saj. Nuk është provë që një ofrues bllokon portën, që një klient dërgoi fjalëkalimin e gabuar ose që zinxhiri i certifikatave është i prishur.

Lexoni gabimin e saktë të lidhjes

Dy gabime në këtë familje nënkuptojnë gjëra të ndryshme, dhe ngatërrimi i tyre ju dërgon në shtresën e gabuar. «Adresa është tashmë në përdorim» thotë se një socket tjetër mban pikën fundore që kërkuat. «Adresa nuk është e disponueshme» thotë se adresa që kërkuat nuk ekziston ende në këtë host, gjë që është problem gatishmërie, jo dublikat.

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

Kopjoni tekstin e gabimit përpara se të ndryshoni çdo gjë, duke përfshirë adresën dhe portën që përmend. Një shërbim që pret të shfaqet një ndërfaqe do të regjistrojë gabimin e dytë vazhdimisht dhe më pas do të lidhet me sukses kur adresa të ekzistojë; një shërbim që regjistron gabimin e parë nuk do të ketë sukses kurrë derisa dublikati të zgjidhet. Shënimi se cilën prej tyre patë nuk kushton asgjë dhe kursen një kërkim të humbur ndërfaqeje.

Inventarizoni socketin, jo portën

Një numër porte është një inventar i paplotë. Pika fundore është një transport, një familje adresash, një adresë lokale dhe një portë, të gjitha brenda një hapësire të vetme emrash rrjeti. Një dëgjues UDP dhe një dëgjues TCP në të njëjtin numër janë sockets të ndryshme, dhe dy procese në të njëjtin numër në hapësira emrash të ndryshme nuk takohen kurrë.

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

Ekzekutoni fillimisht transportin që profili përdor vërtet. Pastaj shikoni kolonën e adresës lokale dhe jo vetëm numrin: një lidhje wildcard mbulon çdo adresë lokale, kështu që një proces i dytë që kërkon një adresë të caktuar mund të përplaset me të edhe pse vargjet e shtypura ndryshojnë. Opsionet e ripërdorimit të socketit dhe rregullat e platformës përcaktojnë rezultatin e saktë, prandaj kjo duhet të jetë një vëzhgim dhe jo një rregull që e zbatoni në çdo vendosje.

Zbuloni cili proces e zotëron

Pikat fundore numerike plus informacioni i procesit identifikojnë pronarin kur privilegjet tuaja e lejojnë, dhe pronari është ajo që ju nevojitet, jo emri i programit. Dy procese OpenVPN mund të ekzekutojnë profile të ndryshme, dhe ai që mban dëgjuesin mund të jetë më i paprituri.

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

Krahasoni atë që gjeni me menaxherin e shërbimeve, një mjedis ekzekutimi kontejnerësh ose një proces terminali të mbetur nga një test i mëparshëm. Mungesa e detajeve të procesit nuk është provë që socketi nuk ka pronar; zakonisht do të thotë që pyetja u ekzekutua pa leje të mjaftueshme. Po ashtu, një listë vetëm me TCP nuk e heq një konflikt UDP, prandaj inspektoni transportin e përmendur në gabim. Vetëm emri i procesit nuk thotë kurrë cili profil u ngarkua, dhe profili është ai që vendos pikën fundore.

Një pronar, ose dy instanca të projektuara

Nëse vendosja synon një server të vetëm, mbani një pronar të vetëm të ciklit të jetës dhe lexoni ditarin e atij instancë ose logun e konfiguruar në vend të nisjes së një kopjeje të dytë për ta vëzhguar. Kur një ekzekutim i kontrolluar në plan të parë është vërtet i nevojshëm, ndaloni me qëllim instancën e menaxhuar dhe merrni parasysh klientët që ajo shërben përpara se ta bëni.

Nëse synohen dy instanca, jepuni dëgjues të veçantë dhe çdo gjë tjetër të veçantë: grupe adresash, ndërfaqe virtuale, politikë rrugëtimi dhe pronësi e konfigurimit. Vetëm një portë e ndryshme nuk ndan asgjë përveç socketit, dhe dy serverët do të vazhdojnë të grindën për të njëjtin grup dhe të njëjtat rrugë.

Tri shkurtore meritojnë të përmenden sepse shfaqen në çdo diskutim për këtë gabim. Mos vrisni një PID arbitrar që duket si fajtori. Mos aktivizoni ndarjen e socketit për ta heshtur mesazhin. Mos e kaloni një profil serveri në një konfigurim të palidhur në stil klienti sepse kjo e bën gabimin e lidhjes të zhduket; serveri bëhet i paarritshëm në një mënyrë më të vështirë për t'u diagnostikuar sesa konflikti origjinal.

Ndryshimi i portës është përgjigje legjitime vetëm kur dëgjuesi i ri është pjesë e një dizajni të miratuar, që përfshin rregullin e përcjelljes dhe pikën fundore të klientit. Nëse ato nuk u përditësuan, e keni zhvendosur konfliktin në një vend ku askush nuk mund ta gjejë.

Verifikoni lidhjen përpara çdo gjëje tjetër

Pas korrigjimit të kufizuar, konfirmoni që instanca e synuar është aktive, që dëgjuesi i saj shfaqet në transportin që prisni dhe që një klient mund të lidhet. Një lidhje e suksesshme plotëson vetëm fazën e socketit lokal; nuk certifikon asgjë për vërtetimin ose për trafikun pasi tuneli të jetë ngritur.

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

Nëse socketi është i pranishëm dhe klienti ende dështon, problemi i mbetur është në rrjedhën e poshtme dhe gabimi i lidhjes tani është histori. Ai ndarje është e gjithë pika e leximit të parë të mesazhit të saktë: një gabim, një shtresë, një pronar. Lexojeni kështu dhe simptoma tjetër do të nisë nga një gjendje e njohur dhe jo nga një supozim.