Port 1194 er allerede i bruk: hvem eier den OpenVPN-socketen?

Start samme serverprofil to ganger, og den andre prosessen avsluttes med en feil om at adressen allerede er i bruk for port 1194. I det vanlige tilfellet skapte den diagnostiske oppstarten konflikten, og den opprinnelige instansen betjener fortsatt klientene helt fint. Denne historien forklarer en stor del av disse rapportene, og det er verdt å kjenne den igjen før noe startes på nytt. Det er også den billigste versjonen å løse.

Feilen beskriver en lokal binding og ingenting utover det. Det er ikke bevis for at en leverandør blokkerer porten, at en klient sendte feil passord, eller at sertifikatkjeden er brutt.

Les den nøyaktige bindingsfeilen

To feil i denne familien betyr forskjellige ting, og å blande dem sammen sender deg til feil lag. «Adressen er allerede i bruk» sier at en annen socket holder endepunktet du ba om. «Adressen er ikke tilgjengelig» sier at adressen du ba om ennå ikke finnes på denne verten, noe som er et beredskapsproblem og ikke en duplikat.

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

Kopier feilteksten før du endrer noe, inkludert adressen og porten den nevner. En tjeneste som venter på at et grensesnitt skal dukke opp, vil logge den andre feilen gjentatte ganger og deretter binde vellykket når adressen finnes; en tjeneste som logger den første feilen, vil aldri lykkes før duplikatet er løst. Å notere hvilken av dem du så, koster ingenting og sparer en bortkastet grensesnittjakt.

Inventar socketen, ikke porten

Et portnummer er en ufullstendig oversikt. Endepunktet er en transport, en adressefamilie, en lokal adresse og en port, alt innenfor ett enkelt nettverksnavnerom. En UDP-lytter og en TCP-lytter på samme nummer er forskjellige sockets, og to prosesser på samme nummer i forskjellige navnerom møtes aldri.

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

Kjør først transporten som profilen faktisk bruker. Se deretter på kolonnen for den lokale adressen i stedet for bare nummeret: en jokertegnbinding dekker alle lokale adresser, så en annen prosess som ber om én bestemt adresse kan kollidere med den selv om de utskrevne strengene er forskjellige. Alternativer for gjenbruk av socket og plattformregler avgjør det nøyaktige resultatet, og derfor bør dette være en observasjon og ikke en regel du bruker på hver utrulling.

Finn ut hvilken prosess som eier den

Numeriske endepunkter pluss prosessinformasjon identifiserer eieren når rettighetene dine tillater det, og eieren er det du trenger, ikke programnavnet. To OpenVPN-prosesser kan kjøre forskjellige profiler, og den som holder lytteren, kan være den du minst venter.

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

Sammenlign det du finner med tjenesteadministratoren, et container-runtime eller en terminalprosess som er til overs fra en tidligere test. Fravær av prosessdetaljer er ikke bevis for at socketen er uten eier; det betyr vanligvis at spørringen kjørte uten tilstrekkelig tillatelse. På samme måte opphever ikke en liste med bare TCP en UDP-konflikt, så undersøk transporten som er nevnt i feilen. Et prosessnavn alene forteller aldri hvilken profil som ble lastet, og profilen er det som avgjør endepunktet.

Én eier, eller to designede instanser

Hvis utrullingen tar sikte på én server, hold én livssykluseier og les journalen til den instansen eller den konfigurerte loggen i stedet for å starte en andre kopi for å overvåke den. Når en kontrollert kjøring i forgrunnen virkelig er nødvendig, stopp den administrerte instansen bevisst og ta hensyn til klientene den betjener før du gjør det.

Hvis to instanser er ment, gi dem forskjellige lyttere og forskjellig alt annet: adressepooler, virtuelle grensesnitt, rutingspolitikk og konfigurasjonseierskap. En annen port alene skiller ingenting annet enn socketen, og de to serverne vil fortsatt kjempe om samme pool og samme ruter.

Tre snarveier er verdt å nevne fordi de dukker opp i hver tråd om denne feilen. Ikke drep en vilkårlig PID som ser ut som synderen. Ikke aktiver socket-deling for å bringe meldingen til taushet. Ikke bytt en serverprofil til en klientlignende ubundet konfigurasjon fordi det får bindingsfeilen til å forsvinne; serveren blir utilgjengelig på en måte som er vanskeligere å diagnostisere enn den opprinnelige konflikten.

Å endre porten er bare et legitimt svar når den nye lytteren er en del av et godkjent design, som inkluderer videresendingsregelen og klientens endepunkt. Hvis disse ikke ble oppdatert, har du flyttet konflikten til et sted der ingen kan finne den.

Bekreft bindingen før alt annet

Etter den avgrensede rettelsen, bekreft at den tiltenkte instansen er aktiv, at lytteren dens vises på transporten du forventer, og at en klient kan koble til. En vellykket binding fullfører bare den lokale socketfasen; den bekrefter ingenting om autentisering eller om trafikk etter at tunnelen er oppe.

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

Hvis socketen er til stede og klienten fortsatt feiler, er det gjenværende problemet nedstrøms og bindingsfeilen er nå historie. Denne separasjonen er hele poenget med å lese den nøyaktige meldingen først: én feil, ett lag, én eier. Les det slik, og neste symptom starter fra en kjent tilstand i stedet for fra en gjetning.