Poort 1194 is al in gebruik: wie bezit die OpenVPN-socket?

Start hetzelfde serverprofiel twee keer en het tweede proces eindigt met een fout dat het adres al in gebruik is voor poort 1194. In het gebruikelijke geval heeft de diagnostische start het conflict veroorzaakt, en de oorspronkelijke instantie bedient de clients nog steeds prima. Dat verhaal verklaart een groot deel van deze meldingen, en het is de moeite waard om het te herkennen voordat er iets opnieuw wordt gestart. Het is ook de goedkoopste versie om op te lossen.

De fout beschrijft een lokale binding en niets daarbuiten. Het is geen bewijs dat een provider de poort blokkeert, dat een client het verkeerde wachtwoord heeft gestuurd, of dat de certificaatketen is gebroken.

Lees de exacte bindingsfout

Twee fouten in deze familie betekenen verschillende dingen, en ze door elkaar halen stuurt u naar de verkeerde laag. „Adres is al in gebruik“ zegt dat een andere socket het gevraagde eindpunt vasthoudt. „Adres is niet beschikbaar“ zegt dat het gevraagde adres nog niet op deze host bestaat, wat een gereedheidsprobleem is en geen duplicaat.

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

Kopieer de fouttekst voordat u iets wijzigt, inclusief het adres en de poort die erin wordt genoemd. Een dienst die wacht tot een interface verschijnt, zal de tweede fout herhaaldelijk loggen en zich dan met succes binden zodra het adres bestaat; een dienst die de eerste fout logt, zal nooit slagen tot het duplicaat is opgelost. Noteren welke van de twee u zag kost niets en bespaart een verspilde interfacejacht.

Inventariseer de socket, niet de poort

Een poortnummer is een onvolledige inventaris. Het eindpunt is een transport, een adresfamilie, een lokaal adres en een poort, allemaal binnen één netwerknaamruimte. Een UDP-listener en een TCP-listener op hetzelfde nummer zijn verschillende sockets, en twee processen op hetzelfde nummer in verschillende naamruimten ontmoeten elkaar nooit.

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

Voer eerst het transport uit dat het profiel werkelijk gebruikt. Kijk dan naar de kolom van het lokale adres in plaats van alleen het nummer: een wildcard-binding dekt elk lokaal adres, dus een tweede proces dat één specifiek adres vraagt kan ermee in botsing komen, zelfs als de afgedrukte strings verschillen. Opties voor hergebruik van sockets en platformregels bepalen de exacte uitkomst, daarom zou dit een observatie moeten zijn en geen regel die u op elke implementatie toepast.

Zoek uit welk proces het bezit

Numerieke eindpunten plus procesinformatie identificeren de eigenaar wanneer uw rechten dat toelaten, en de eigenaar is wat u nodig hebt, niet de programmanaam. Twee OpenVPN-processen kunnen verschillende profielen draaien, en degene die de listener vasthoudt kan degene zijn die u het minst verwacht.

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

Vergelijk wat u vindt met de servicemanager, een containerruntime of een terminalproces dat overblijft van een eerdere test. Het ontbreken van procesdetails is geen bewijs dat de socket geen eigenaar heeft; het betekent meestal dat de query zonder voldoende rechten liep. Evenzo heft een lijst met alleen TCP een UDP-conflict niet op, dus inspecteer het transport dat in de fout wordt genoemd. Een procesnaam alleen vertelt nooit welk profiel is geladen, en het profiel is wat het eindpunt bepaalt.

Eén eigenaar, of twee ontworpen instanties

Als de implementatie één server bedoelt, houd dan één levenscycluseigenaar en lees het journaal van die instantie of de geconfigureerde log in plaats van een tweede kopie te starten om die te observeren. Wanneer een gecontroleerde voorgrondrun echt nodig is, stop de beheerde instantie dan bewust en houd vooraf rekening met de clients die zij bedient.

Als twee instanties bedoeld zijn, geef ze dan verschillende listeners en verschillende al het andere: adrespoelen, virtuele interfaces, routeringsbeleid en configuratie-eigendom. Een andere poort alleen scheidt niets anders dan de socket, en de twee servers vechten nog steeds om dezelfde poel en dezelfde routes.

Drie snelkoppelingen verdienen het genoemd te worden omdat ze in elke thread over deze fout voorkomen. Dood geen willekeurige PID die op de schuldige lijkt. Schakel geen socket-deling in om het bericht het zwijgen op te leggen. Schakel een serverprofiel niet om naar een clientachtige niet-gebonden configuratie omdat daardoor de bindingsfout verdwijnt; de server wordt onbereikbaar op een manier die moeilijker te diagnosticeren is dan het oorspronkelijke conflict.

De poort wijzigen is alleen een legitiem antwoord wanneer de nieuwe listener deel uitmaakt van een goedgekeurd ontwerp, dat de doorstuurregel en het cliënteindpunt omvat. Als die niet zijn bijgewerkt, hebt u het conflict verplaatst naar een plek waar niemand het kan vinden.

Verifieer de binding vóór al het andere

Na de beperkte correctie, bevestig dat de bedoelde instantie actief is, dat haar listener op het verwachte transport verschijnt, en dat een client kan verbinden. Een geslaagde binding voltooit alleen de lokale socketfase; zij bevestigt niets over authenticatie of over verkeer zodra de tunnel staat.

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

Als de socket aanwezig is en de client nog steeds faalt, ligt het resterende probleem stroomafwaarts en is de bindingsfout nu geschiedenis. Die scheiding is het hele punt van eerst het exacte bericht lezen: één fout, één laag, één eigenaar. Lees het zo, en het volgende symptoom begint bij een bekende toestand in plaats van bij een gok.