Portul 1194 este deja utilizat: cui aparține acel socket OpenVPN?

Porniți același profil de server de două ori, iar al doilea proces se termină cu o eroare că adresa este deja utilizată pentru portul 1194. În cazul obișnuit, lansarea de diagnostic a creat conflictul, iar instanța originală încă servește clienții perfect. Această poveste explică o mare parte din aceste rapoarte și merită recunoscută înainte de a reporni ceva. Este și cea mai ieftină versiune de rezolvat.

Eroarea descrie o legare locală și nimic dincolo de ea. Nu este dovada că un furnizor blochează portul, că un client a trimis parola greșită sau că lanțul de certificate este rupt.

Citiți eroarea exactă de legare

Două erori din această familie înseamnă lucruri diferite, iar confundarea lor vă trimite la stratul greșit. «Adresa este deja utilizată» spune că un alt socket deține punctul final pe care l-ați cerut. «Adresa nu este disponibilă» spune că adresa cerută nu există încă pe acest gazdă, ceea ce este o problemă de pregătire, nu un duplicat.

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

Copiați textul erorii înainte de a schimba ceva, inclusiv adresa și portul pe care le numește. Un serviciu care așteaptă apariția unei interfețe va înregistra a doua eroare în mod repetat și apoi se va lega cu succes când adresa există; un serviciu care înregistrează prima eroare nu va reuși niciodată până când duplicatul nu este rezolvat. Notarea căreia dintre ele ați văzut-o nu costă nimic și economisește o căutare de interfețe irosită.

Inventariați socketul, nu portul

Un număr de port este un inventar incomplet. Punctul final este un transport, o familie de adrese, o adresă locală și un port, totul într-un singur spațiu de nume de rețea. Un ascultător UDP și un ascultător TCP pe același număr sunt socketuri diferite, iar două procese pe același număr în spații de nume diferite nu se întâlnesc niciodată.

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

Rulați mai întâi transportul pe care profilul îl folosește efectiv. Apoi priviți coloana adresei locale, nu doar numărul: o legare wildcard acoperă fiecare adresă locală, astfel încât un al doilea proces care cere o adresă anume poate intra în coliziune cu ea chiar dacă șirurile tipărite diferă. Opțiunile de reutilizare a socketului și regulile platformei decid rezultatul exact, de aceea acesta ar trebui să fie o observație, nu o regulă pe care o aplicați fiecărei implementări.

Aflați ce proces îl deține

Punctele finale numerice plus informațiile despre proces identifică proprietarul când privilegiile dumneavoastră permit acest lucru, iar proprietarul este ceea ce aveți nevoie, nu numele programului. Două procese OpenVPN pot rula profiluri diferite, iar cel care deține ascultătorul poate fi cel la care vă așteptați cel mai puțin.

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

Comparați ceea ce găsiți cu managerul de servicii, un runtime de containere sau un proces de terminal rămas de la un test anterior. Absența detaliilor despre proces nu este dovada că socketul nu are proprietar; de obicei înseamnă că interogarea a rulat fără permisiuni suficiente. La fel, o listă doar cu TCP nu înlătură un conflict UDP, deci inspectați transportul numit în eroare. Numele procesului singur nu spune niciodată ce profil a fost încărcat, iar profilul este cel care decide punctul final.

Un proprietar, sau două instanțe proiectate

Dacă implementarea intenționează un singur server, păstrați un singur proprietar al ciclului de viață și citiți jurnalul acelei instanțe sau logul configurat în loc să lansați o a doua copie pentru a o observa. Când o rulare controlată în prim-plan este cu adevărat necesară, opriți deliberat instanța gestionată și aveți în vedere clienții pe care îi servește înainte de a face asta.

Dacă se intenționează două instanțe, dați-le ascultători distincți și tot restul distinct: pool-uri de adrese, interfețe virtuale, politică de rutare și proprietatea configurației. Doar un port diferit nu separă nimic altceva decât socketul, iar cele două servere vor continua să se certe pe același pool și aceleași rute.

Trei scurtături merită numite pentru că apar în fiecare discuție despre această eroare. Nu omorâți un PID arbitrar care pare vinovatul. Nu activați partajarea socketului pentru a reduce mesajul la tăcere. Nu comutați un profil de server într-o configurație nelegată de stil client pentru că asta face eroarea de legare să dispară; serverul devine inaccesibil într-un mod mai greu de diagnosticat decât conflictul original.

Schimbarea portului este un răspuns legitim doar când noul ascultător face parte dintr-un proiect aprobat, care include regula de redirecționare și punctul final al clientului. Dacă acestea nu au fost actualizate, ați mutat conflictul într-un loc unde nimeni nu îl poate găsi.

Verificați legarea înainte de orice altceva

După corectarea limitată, confirmați că instanța intenționată este activă, că ascultătorul ei apare pe transportul așteptat și că un client se poate conecta. O legare reușită completează doar etapa socketului local; nu certifică nimic despre autentificare sau despre trafic după ce tunelul este ridicat.

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

Dacă socketul este prezent și clientul încă eșuează, problema rămasă este în aval și eroarea de legare este acum istorie. Această separare este tot sensul citirii mai întâi a mesajului exact: o eroare, un strat, un proprietar. Citiți-o astfel și următorul simptom va începe dintr-o stare cunoscută, nu dintr-o presupunere.