1194 prievadas jau naudojamas: kam priklauso tas OpenVPN lizdas?

Paleiskite tą pačią serverio profilį du kartus, ir antrasis procesas baigiasi klaida, kad adresas jau naudojamas prievadui 1194. Įprastu atveju konfliktą sukūrė diagnostinis paleidimas, o pradinė instancija vis dar puikiai aptarnauja klientus. Ši istorija paaiškina didelę dalį šių pranešimų, ir verta ją atpažinti prieš ką nors paleidžiant iš naujo. Tai taip pat pigiausias sprendimo variantas.

Klaida apibūdina vietinį susiejimą ir nieko daugiau. Tai nėra įrodymas, kad teikėjas blokuoja prievadą, kad klientas išsiuntė neteisingą slaptažodį arba kad sertifikatų grandinė sulaužyta.

Perskaitykite tikslią susiejimo klaidą

Dvi šios šeimos klaidos reiškia skirtingus dalykus, o jų painiojimas nukreipia jus į netinkamą sluoksnį. „Adresas jau naudojamas“ reiškia, kad kitas lizdas laiko jūsų prašomą galinį tašką. „Adresas neprieinamas“ reiškia, kad prašomo adreso šiame pagrindiniame kompiuteryje dar nėra, ir tai yra pasirengimo problema, o ne dublikatas.

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

Nukopijuokite klaidos tekstą prieš ką nors keisdami, įskaitant nurodytą adresą ir prievadą. Tarnyba, kuri laukia sąsajos pasirodymo, antrąją klaidą registruos pakartotinai ir tada sėkmingai susies, kai adresas atsiras; tarnyba, kuri registruoja pirmąją klaidą, niekada nepavyks, kol dublikatas nebus išspręstas. Užsirašyti, kurią iš jų matėte, nieko nekainuoja ir sutaupo bergždžią sąsajos paiešką.

Inventorizuokite lizdą, o ne prievadą

Prievado numeris yra nepilna inventorizacija. Galinis taškas yra transportas, adresų šeima, vietinis adresas ir prievadas, viskas vieno tinklo vardų erdvėje. UDP klausytojas ir TCP klausytojas tuo pačiu numeriu yra skirtingi lizdai, o du procesai tuo pačiu numeriu skirtingose vardų erdvėse niekada nesusitinka.

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

Pirmiausia paleiskite transportą, kurį profilis iš tikrųjų naudoja. Tada žiūrėkite į vietinio adreso stulpelį, o ne tik į numerį: pakaitinis susiejimas apima visus vietinius adresus, todėl antrasis procesas, prašantis vieno konkretaus adreso, gali su juo susidurti, net jei atspausdintos eilutės skiriasi. Lizdo pakartotinio naudojimo parinktys ir platformos taisyklės nulemia tikslų rezultatą, todėl tai turėtų būti stebėjimas, o ne taisyklė, kurią taikote kiekvienam diegimui.

Išsiaiškinkite, kuris procesas jį valdo

Skaitmeniniai galiniai taškai ir proceso informacija nustato savininką, kai jūsų privilegijos tai leidžia, ir jums reikia savininko, o ne programos pavadinimo. Du OpenVPN procesai gali vykdyti skirtingus profilius, o tą, kuris laiko klausytoją, galite įtarti mažiausiai.

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

Palyginkite tai, ką radote, su paslaugų tvarkykle, konteinerių vykdymo aplinka arba terminalo procesu, likusiu iš ankstesnio bandymo. Proceso informacijos nebuvimas nėra įrodymas, kad lizdas neturi savininko; paprastai tai reiškia, kad užklausa buvo vykdyta be pakankamų teisių. Taip pat sąrašas tik su TCP nepanaikina UDP konflikto, todėl patikrinkite klaidoje nurodytą transportą. Vien proceso pavadinimas niekada nepasako, kuris profilis buvo įkeltas, ir būtent profilis nulemia galinį tašką.

Vienas savininkas, arba dvi suprojektuotos instancijos

Jei diegimas numato vieną serverį, laikykitės vieno gyvavimo ciklo savininko ir skaitykite tos instancijos žurnalą arba sukonfigūruotą žurnalą, o ne paleiskite antrą kopiją jai stebėti. Kai kontroliuojamas paleidimas pirmame plane tikrai būtinas, sąmoningai sustabdykite valdomą instanciją ir prieš tai atsižvelkite į klientus, kuriems ji teikia paslaugas.

Jei numatomos dvi instancijos, suteikite joms atskirus klausytojus ir atskirkite visa kita: adresų telkinius, virtualias sąsajas, maršrutizavimo politiką ir konfigūracijos nuosavybę. Vien kitas prievadas atskiria tik lizdą, ir abu serveriai vis tiek kovos dėl to paties telkinio ir tų pačių maršrutų.

Trys gudrybės vertos paminėjimo, nes jos pasirodo kiekvienoje temoje apie šią klaidą. Nežudykite savavališko PID, kuris atrodo kaltas. Neįjunkite lizdo bendrinimo, kad nutildytumėte pranešimą. Neperjunkite serverio profilio į kliento stiliaus nesusietą konfigūraciją, nes dėl to susiejimo klaida išnyksta; serveris tampa nepasiekiamas taip, kad jį diagnozuoti sunkiau nei pradinį konfliktą.

Prievado keitimas yra teisėtas atsakymas tik tada, kai naujasis klausytojas yra patvirtinto dizaino dalis, įskaitant persiuntimo taisyklę ir kliento galinį tašką. Jei jie nebuvo atnaujinti, jūs perkėlėte konfliktą į vietą, kurioje niekas negali jo rasti.

Patikrinkite susiejimą prieš visa kita

Po ribotos pataisos patvirtinkite, kad numatyta instancija yra aktyvi, kad jos klausytojas pasirodo laukiamame transporte ir kad klientas gali prisijungti. Sėkmingas susiejimas tik užbaigia vietinio lizdo etapą; jis nieko neliudija apie autentifikavimą arba apie srautą po tunelio pakėlimo.

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

Jei lizdas yra, o klientas vis tiek nepavyksta, likusi problema yra pasroviui ir susiejimo klaida jau istorija. Būtent šis atskyrimas yra visa tikslios žinutės pirmiausia skaitymo prasmė: viena klaida, vienas sluoksnis, vienas savininkas. Skaitykite taip, ir kitas simptomas prasidės nuo žinomos būsenos, o ne nuo spėjimo.