Vrata 1194 so že v uporabi: komu pripada ta socket OpenVPN?

Zaženite isti profil strežnika dvakrat in drugi proces se konča z napako, da je naslov že v uporabi za vrata 1194. V običajnem primeru je konflikt ustvaril diagnostični zagon, prvotna instanca pa še vedno povsem dobro streže odjemalcem. Ta zgodba pojasnjuje velik del teh poročil in vredno jo je prepoznati, preden karkoli znova zaženete. To je tudi najcenejša različica rešitve.

Napaka opisuje lokalno povezavo in nič onkraj nje. Ni dokaz, da ponudnik blokira vrata, da je odjemalec poslal napačno geslo ali da je veriga potrdil zlomljena.

Preberite natančno napako povezave

Dve napaki iz te družine pomenita različne stvari in njuna zamenjava vas pošlje na napačno plast. „Naslov je že v uporabi“ pravi, da drug socket drži zahtevano končno točko. „Naslov ni na voljo“ pravi, da zahtevani naslov na tem gostitelju še ne obstaja, kar je težava pripravljenosti, ne dvojnik.

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

Kopirajte besedilo napake, preden karkoli spremenite, vključno z naslovom in vrati, ki jih navaja. Storitev, ki čaka na pojav vmesnika, bo drugo napako zapisovala znova in znova ter se nato uspešno povezala, ko bo naslov obstajal; storitev, ki zapisuje prvo napako, nikoli ne bo uspela, dokler dvojnik ne bo rešen. Zapis, katero od njiju ste videli, nič ne stane in prihrani zapravljeno iskanje vmesnika.

Popišite socket, ne vrat

Številka vrat je nepopoln popis. Končna točka je transport, družina naslovov, lokalni naslov in vrata, vse znotraj enega omrežnega imenskega prostora. Poslušalec UDP in poslušalec TCP na isti številki sta različna socketa, dva procesa na isti številki v različnih imenskih prostorih pa se nikoli ne srečata.

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

Najprej zaženite transport, ki ga profil dejansko uporablja. Nato poglejte stolpec lokalnega naslova in ne le številke: povezava z nadomestnim znakom pokriva vsak lokalni naslov, zato lahko drug proces, ki zahteva en določen naslov, trči z njo, čeprav se natisnjeni nizi razlikujejo. Možnosti ponovne uporabe socketa in pravila platforme določajo natančen izid, zato bi to moralo biti opažanje in ne pravilo, ki ga uporabite pri vsaki namestitvi.

Ugotovite, kateri proces ga ima v lasti

Številčne končne točke in podatki o procesu prepoznajo lastnika, ko vam to dovolijo pravice, in lastnik je tisto, kar potrebujete, ne ime programa. Dva procesa OpenVPN lahko izvajata različne profile, tisti, ki drži poslušalca, pa je lahko najmanj pričakovan.

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

Primerjajte, kar najdete, z upraviteljem storitev, izvajalnim okoljem vsebnikov ali terminalskim procesom, ki je ostal od prejšnjega preskusa. Odsotnost podrobnosti o procesu ni dokaz, da socket nima lastnika; običajno pomeni, da je poizvedba tekla brez zadostnih dovoljenj. Prav tako seznam samo s TCP ne odpravi konflikta UDP, zato preglejte transport, naveden v napaki. Samo ime procesa nikoli ne pove, kateri profil je bil naložen, in profil je tisti, ki določi končno točko.

En lastnik ali dve načrtovani instanci

Če namestitev predvideva en strežnik, ohranite enega lastnika življenjskega cikla in berite dnevnik te instance ali konfigurirano beleženje, namesto da zaženete drugo kopijo, da bi jo opazovali. Ko je nadzorovani zagon v ospredju resnično potreben, namerno ustavite upravljano instanco in pred tem upoštevajte odjemalce, ki jim streže.

Če sta predvideni dve instanci, jima dajte ločene poslušalce in ločeno vse ostalo: nabori naslovov, navidezni vmesniki, usmerjevalna politika in lastništvo konfiguracije. Samo drugačna vrata ločijo le socket, oba strežnika pa se bosta še vedno prepirala za isti nabor in iste poti.

Tri bližnjice velja omeniti, ker se pojavljajo v vsaki razpravi o tej napaki. Ne ubijajte poljubnega PID, ki izgleda kot krivec. Ne omogočite deljenja socketa, da bi utišali sporočilo. Ne preklapljajte profila strežnika v odjemalcu podobno nepovezano konfiguracijo, ker to povzroči, da napaka povezave izgine; strežnik postane nedosegljiv na način, ki ga je težje diagnosticirati kot prvotni konflikt.

Sprememba vrat je legitimen odgovor le, kadar je novi poslušalec del odobrene zasnove, ki vključuje pravilo posredovanja in končno točko odjemalca. Če ti nista bili posodobljeni, ste konflikt premaknili na mesto, kjer ga nihče ne najde.

Preverite povezavo pred vsem drugim

Po omejenem popravku potrdite, da je predvidena instanca aktivna, da se njen poslušalec pojavi na pričakovanem transportu in da se odjemalec lahko poveže. Uspešna povezava dokonča le fazo lokalnega socketa; ne potrjuje ničesar o preverjanju pristnosti ali o prometu po dvigu tunela.

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

Če socket obstaja in odjemalec še vedno ne uspe, je preostala težava nižje in napaka povezave je zdaj zgodovina. Prav ta ločitev je ves smisel tega, da najprej preberete natančno sporočilo: ena napaka, ena plast, en lastnik. Berite tako in naslednji simptom se bo začel iz znanega stanja, ne iz ugibanja.