Port 1194 används redan: vem äger den OpenVPN-socketen?

Starta samma serverprofil två gånger, och den andra processen avslutas med ett fel om att adressen redan används för port 1194. I det vanliga fallet skapade den diagnostiska starten konflikten, och den ursprungliga instansen betjänar fortfarande klienterna helt fint. Den här historien förklarar en stor del av dessa rapporter, och det är värt att känna igen den innan något startas om. Det är också den billigaste versionen att lösa.

Felet beskriver en lokal bindning och ingenting bortom den. Det är inte bevis för att en leverantör blockerar porten, att en klient skickade fel lösenord eller att certifikatkedjan är bruten.

Läs det exakta bindningsfelet

Två fel i denna familj betyder olika saker, och att blanda ihop dem skickar dig till fel lager. ”Adressen används redan” säger att en annan socket håller den slutpunkt du bad om. ”Adressen är inte tillgänglig” säger att adressen du bad om ännu inte finns på den här värden, vilket är ett beredskapsproblem och inte en dubblett.

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

Kopiera feltexten innan du ändrar något, inklusive adressen och porten den nämner. En tjänst som väntar på att ett gränssnitt ska dyka upp kommer att logga det andra felet upprepade gånger och sedan binda framgångsrikt när adressen finns; en tjänst som loggar det första felet kommer aldrig att lyckas förrän dubbletten är löst. Att anteckna vilket av dem du såg kostar ingenting och sparar en bortkastad gränssnittsjakt.

Inventera socketen, inte porten

Ett portnummer är en ofullständig inventering. Slutpunkten är en transport, en adressfamilj, en lokal adress och en port, allt inom ett enda nätverksnamnutrymme. En UDP-lyssnare och en TCP-lyssnare på samma nummer är olika sockets, och två processer på samma nummer i olika namnutrymmen möts aldrig.

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

Kör först den transport som profilen faktiskt använder. Titta sedan på kolumnen för den lokala adressen i stället för bara numret: en jokerteckenbindning täcker varje lokal adress, så en andra process som ber om en specifik adress kan kollidera med den även om de utskrivna strängarna skiljer sig. Alternativ för återanvändning av socket och plattformsregler avgör det exakta resultatet, och därför bör detta vara en observation och inte en regel du tillämpar på varje utrullning.

Ta reda på vilken process som äger den

Numeriska slutpunkter plus processinformation identifierar ägaren när dina behörigheter tillåter det, och ägaren är det du behöver, inte programnamnet. Två OpenVPN-processer kan köra olika profiler, och den som håller lyssnaren kan vara den du minst väntar.

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

Jämför det du hittar med tjänstehanteraren, en container-runtime eller en terminalprocess som blivit kvar från ett tidigare test. Avsaknad av processdetaljer är inte bevis för att socketen saknar ägare; det betyder vanligtvis att frågan kördes utan tillräcklig behörighet. På samma sätt undanröjer inte en lista med bara TCP en UDP-konflikt, så undersök transporten som nämns i felet. Ett processnamn ensamt berättar aldrig vilken profil som laddades, och profilen är det som avgör slutpunkten.

En ägare, eller två designade instanser

Om utrullningen avser en server, behåll en livscykelägare och läs den instansens journal eller den konfigurerade loggen i stället för att starta en andra kopia för att övervaka den. När en kontrollerad körning i förgrunden verkligen är nödvändig, stoppa den hanterade instansen medvetet och ta hänsyn till klienterna den betjänar innan du gör det.

Om två instanser avses, ge dem separata lyssnare och separat allt annat: adresspooler, virtuella gränssnitt, routningspolicy och konfigurationsägande. En annan port ensam skiljer ingenting annat än socketen, och de två servrarna kommer fortfarande att slåss om samma pool och samma rutter.

Tre genvägar förtjänar att nämnas eftersom de dyker upp i varje tråd om detta fel. Döda inte en godtycklig PID som ser ut som boven. Aktivera inte socket-delning för att tysta meddelandet. Byt inte en serverprofil till en klientliknande obunden konfiguration eftersom det får bindningsfelet att försvinna; servern blir oåtkomlig på ett sätt som är svårare att diagnostisera än den ursprungliga konflikten.

Att byta port är bara ett legitimt svar när den nya lyssnaren är en del av en godkänd design, som inkluderar vidarebefordringsregeln och klientens slutpunkt. Om dessa inte uppdaterades har du flyttat konflikten till en plats där ingen kan hitta den.

Verifiera bindningen före allt annat

Efter den avgränsade korrigeringen, bekräfta att den avsedda instansen är aktiv, att dess lyssnare visas på den transport du förväntar dig och att en klient kan ansluta. En lyckad bindning slutför bara den lokala socketfasen; den intygar ingenting om autentisering eller om trafik efter att tunneln rests.

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

Om socketen finns och klienten fortfarande misslyckas, är det återstående problemet nedströms och bindningsfelet är nu historia. Den separationen är hela poängen med att läsa det exakta meddelandet först: ett fel, ett lager, en ägare. Läs det så, och nästa symptom börjar från ett känt tillstånd i stället för från en gissning.