Poort 1194 word al gebruik: wie besit daardie OpenVPN-sok?

Begin dieselfde bedienerprofiel twee keer, en die tweede proses stop met ’n fout dat die adres in gebruik is vir poort 1194. In die algemene geval het die diagnostiese bekendstelling die konflik geskep, en die oorspronklike instansie bedien steeds kliënte heeltemal goed. Daardie verhaal verteenwoordig ’n groot deel van hierdie verslae, en dit is die moeite werd om dit te herken voordat enigiets herbegin word. Dit is ook die goedkoopste weergawe om op te los.

Die fout beskryf ’n plaaslike binding en niks daarbuite nie. Dit is nie ’n bewys dat ’n verskaffer die poort blokkeer, dat ’n kliënt die verkeerde wagwoord gestuur het, of dat die sertifikaatketting gebreek is nie.

Lees die presiese bindingsfout

Twee foute in hierdie familie beteken verskillende dinge, en om hulle te verwar stuur jou na die verkeerde laag. Adres word al gebruik sê dat ’n ander sok die eindpunt hou wat jy aangevra het. Adres nie beskikbaar nie sê dat die adres wat jy aangevra het nog nie op hierdie gasheer bestaan nie, wat ’n gereedheidsprobleem eerder as ’n duplikaat is.

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

Kopieer die foutteks voordat jy enigiets verander, insluitend die adres en poort wat dit noem. ’n Diens wat wag vir ’n koppelvlak om te verskyn, sal die tweede fout herhaaldelik log en dan suksesvol bind sodra die adres bestaan; ’n diens wat die eerste fout log, sal nooit slaag voordat die duplikaat opgelos is nie. Om te noteer watter een jy gesien het, kos niks en spaar ’n vermorste soektog na koppelvlakke.

Inventariseer die sok, nie die poort nie

’n Poortnommer is ’n onvolledige inventaris. Die eindpunt is ’n transport, ’n adresfamilie, ’n plaaslike adres en ’n poort, alles binne een netwerknaamruimte. ’n UDP-luisteraar en ’n TCP-luisteraar op dieselfde nommer is verskillende sokke, en twee prosesse op dieselfde nommer in verskillende naamruimtes ontmoet nooit.

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

Voer eers die transport uit wat die profiel werklik gebruik. Kyk dan na die kolom vir die plaaslike adres eerder as net na die nommer: ’n wildcard-binding dek elke plaaslike adres, so ’n tweede proses wat een spesifieke adres vra, kan daarmee bots selfs al verskil die gedrukte stringe. Hergebruikopsies vir sokke en platformreëls bepaal die presiese uitkoms, en daarom behoort dit ’n waarneming te wees eerder as ’n reël wat jy op elke ontplooiing toepas.

Vind watter proses dit besit

Numeriese eindpunte plus prosesinligting identifiseer die eienaar wanneer jou voorregte dit toelaat, en die eienaar is wat jy nodig het, nie die programnaam nie. Twee OpenVPN-prosesse kan verskillende profiele dra, en die een wat die luisteraar hou, kan die een wees wat jy die minste vermoed.

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

Vergelyk wat jy vind met die diensbestuurder, ’n houerruntime of ’n terminalproses wat van ’n vroeëre toets oorgebly het. Die afwesigheid van prosesbesonderhede is nie bewyse dat die sok sonder eienaar is nie; dit beteken gewoonlik dat die navraag sonder genoeg toestemming geloop het. Net so ruim ’n lys wat net TCP toon nie ’n UDP-konflik op nie, so ondersoek die transport wat in die fout genoem word. ’n Prosesnaam alleen sê nooit watter profiel gelaai is nie, en die profiel is wat die eindpunt bepaal.

Een eienaar, of twee beplande instansies

As die ontplooiing een bediener bedoel, hou een lewensikluseienaar en lees daardie instansie se joernaal of gekonfigureerde log in plaas daarvan om ’n tweede kopie te begin om dit dop te hou. Wanneer ’n beheerde voorgrondloop werklik nodig is, stop die bestuurde instansie doelbewus en verantwoord die kliënte wat dit bedien voordat jy dit doen.

As twee instansies bedoel is, gee hulle verskillende luisteraars en verskillende alles anders: adrespoele, virtuele koppelvlakke, roeteringsbeleid en konfigurasie-eienaarskap. ’n Ander poort alleen skei niks buiten die sok nie, en die twee bedieners sal steeds oor dieselfde poel en dieselfde roetes baklei.

Drie kortpaaie is die moeite werd om te noem, want hulle verskyn in elke draad oor hierdie fout. Moenie ’n willekeurige PID doodmaak wat soos die skuldige lyk nie. Moenie sokhergebruik aktiveer om die boodskap stil te maak nie. Moenie ’n bedienerprofiel na ’n kliëntagtige ongebonde konfigurasie oorskakel nie, want dit laat die bindingsfout verdwyn; die bediener word dan onbereikbaar op ’n manier wat moeiliker is om te diagnoseer as die oorspronklike konflik.

Om die poort te verander is net ’n geldige antwoord wanneer die nuwe luisteraar deel van ’n goedgekeurde ontwerp is, wat die deurvoerreël en die kliënt-eindpunt insluit. As dit nie opgedateer is nie, het jy die konflik na ’n plek geskuif waar niemand dit kan vind nie.

Verifieer die binding voor enigiets anders

Ná die beperkte regstelling, bevestig dat die bedoelde instansie aktief is, dat sy luisteraar op die transport verskyn wat jy verwag, en dat ’n kliënt kan verbind. ’n Suksesvolle binding voltooi net die plaaslike sok-stadium; dit sertifiseer niks oor verifikasie of oor verkeer sodra die tonnel op is nie.

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

As die sok teenwoordig is en die kliënt steeds misluk, is die oorblywende probleem stroomaf en is die bindingsfout nou geskiedenis. Daardie skeiding is die hele punt daarvan om eers die presiese boodskap te lees: een fout, een laag, een eienaar. Lees dit so, en die volgende simptoom begin by ’n bekende toestand eerder as by ’n raaiskoot.