Port 1194 er allerede i brug: hvem ejer den OpenVPN-socket?

Start den samme serverprofil to gange, og den anden proces afsluttes med en fejl om, at adressen er i brug, for port 1194. I det almindelige tilfælde skabte den diagnostiske start konflikten, og den oprindelige instans betjener stadig klienter helt fint. Den historie forklarer en stor del af disse rapporter, og det er værd at genkende den, før noget genstartes. Det er også den billigste version at løse.

Fejlen beskriver en lokal binding og intet ud over den. Det er ikke bevis for, at en udbyder blokerer porten, at en klient sendte den forkerte adgangskode, eller at certifikatkæden er brudt.

Læs den præcise bindingsfejl

To fejl i denne familie betyder forskellige ting, og at blande dem sammen sender dig til det forkerte lag. „Adressen er allerede i brug“ siger, at en anden socket holder det endepunkt, du bad om. „Adressen er ikke tilgængelig“ siger, at den adresse, du bad om, endnu ikke findes på denne vært, hvilket er et parathedsproblem snarere end en dublet.

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

Kopier fejlteksten, før du ændrer noget, inklusive den adresse og port, den nævner. En tjeneste, der venter på, at en grænseflade dukker op, vil logge den anden fejl gentagne gange og derefter binde korrekt, når adressen findes; en tjeneste, der logger den første fejl, vil aldrig lykkes, før dubletten er løst. At notere, hvilken af dem du så, koster intet og sparer en spildt grænsefladejagt.

Kortlæg socketen, ikke porten

Et portnummer er en ufuldstændig fortegnelse. Endepunktet er en transport, en adressefamilie, en lokal adresse og en port, alt sammen inde i ét netværksnavnerum. En UDP-lytter og en TCP-lytter på samme nummer er forskellige sockets, og to processer på samme nummer i forskellige navnerum mødes aldrig.

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

Kør først den transport, som profilen faktisk bruger. Se derefter på kolonnen for den lokale adresse i stedet for kun nummeret: en wildcard-binding dækker alle lokale adresser, så en anden proces, der beder om én bestemt adresse, kan kollidere med den, selv om de udskrevne strenge er forskellige. Socket-genbrugsindstillinger og platformregler afgør det præcise resultat, og derfor bør dette være en observation snarere end en regel, du anvender på hver udrulning.

Find ud af, hvilken proces der ejer den

Numeriske endepunkter plus procesoplysninger identificerer ejeren, når dine rettigheder tillader det, og ejeren er det, du har brug for, ikke programnavnet. To OpenVPN-processer kan køre forskellige profiler, og den, der holder lytteren, kan være den, du mindst venter.

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

Sammenlign det, du finder, med tjenestestyringen, en container-runtime eller en terminalproces tilbage fra en tidligere test. Fravær af procesdetaljer er ikke bevis for, at socketen er uden ejer; det betyder normalt, at forespørgslen kørte uden tilstrækkelig tilladelse. På samme måde opvejer en liste med kun TCP ikke en UDP-konflikt, så undersøg den transport, der nævnes i fejlen. Et procesnavn alene fortæller aldrig, hvilken profil der blev indlæst, og profilen er det, der bestemmer endepunktet.

Én ejer eller to designede instanser

Hvis udrulningen sigter mod én server, skal du holde én livscyklusejer og læse den instans’ journal eller konfigurerede log i stedet for at starte en anden kopi for at overvåge den. Når en kontrolleret kørsel i forgrunden er virkelig nødvendig, skal du stoppe den administrerede instans bevidst og tage højde for de klienter, den betjener, før du gør det.

Hvis to instanser er tilsigtet, skal du give dem forskellige lyttere og forskelligt alt andet: adressepuljer, virtuelle grænseflader, routingpolitik og konfigurationsejerskab. En anden port alene adskiller intet undtagen socketen, og de to servere vil stadig kæmpe om den samme pulje og de samme ruter.

Tre genveje er værd at nævne, fordi de optræder i enhver tråd om denne fejl. Dræb ikke en vilkårlig PID, der ligner synderen. Aktivér ikke socket-deling for at bringe meddelelsen til tavshed. Skift ikke en serverprofil til en klientlignende ubundet konfiguration, fordi det får bindingsfejlen til at forsvinde; serveren holder op med at være tilgængelig på en måde, der er sværere at diagnosticere end den oprindelige konflikt.

At ændre porten er kun et legitimt svar, når den nye lytter er en del af et godkendt design, som omfatter videresendelsesreglen og klientens endepunkt. Hvis de ikke blev opdateret, har du flyttet konflikten til et sted, hvor ingen kan finde den.

Bekræft bindingen før alt andet

Efter den afgrænsede rettelse skal du bekræfte, at den tilsigtede instans er aktiv, at dens lytter optræder på den transport, du forventer, og at en klient kan oprette forbindelse. En vellykket binding fuldender kun den lokale socket-fase; den bekræfter intet om godkendelse eller om trafik, når 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 stadig fejler, er det resterende problem nedstrøms, og bindingsfejlen er nu historie. Den adskillelse er hele pointen i at læse den præcise meddelelse først: én fejl, ét lag, én ejer. Læs det sådan, og det næste symptom starter fra en kendt tilstand i stedet for fra et gæt.