Az 1194-es port már használatban van: kié ez az OpenVPN-socket?

Indítsa el ugyanazt a kiszolgálóprofilt kétszer, és a második folyamat a cím már használatban hibával lép ki az 1194-es portnál. A szokásos esetben a diagnosztikai indítás hozta létre az ütközést, és az eredeti példány továbbra is tökéletesen kiszolgálja az ügyfeleket. Ez a történet magyarázza e jelentések nagy részét, és érdemes felismerni, mielőtt bármit újraindítana. Ez a legolcsóbb megoldási változat is.

A hiba helyi kötést ír le, és semmit azon túl. Nem bizonyítja, hogy egy szolgáltató blokkolja a portot, hogy egy ügyfél rossz jelszót küldött, vagy hogy a tanúsítványlánc sérült.

Olvassa el a pontos kötési hibát

Két hiba ebből a családból különböző dolgokat jelent, és összekeverésük a rossz rétegre küldi. „A cím már használatban van“ azt jelenti, hogy egy másik socket birtokolja a kért végpontot. „A cím nem érhető el“ azt jelenti, hogy a kért cím még nem létezik ezen a gazdagépen, ami készenléti probléma, nem pedig duplikátum.

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

Másolja ki a hiba szövegét, mielőtt bármit módosít, beleértve az abban szereplő címet és portot. Egy szolgáltatás, amely egy interfész megjelenésére vár, ismételten naplózza a második hibát, majd sikeresen köt, amint a cím létezik; egy szolgáltatás, amely az első hibát naplózza, soha nem fog sikerülni, amíg a duplikátum meg nem oldódik. Feljegyezni, melyiket látta, nem kerül semmibe, és megspórol egy elvesztegetett interfészkutatást.

A socketet leltározza, ne a portot

A portszám hiányos leltár. A végpont egy szállítás, egy címcsalád, egy helyi cím és egy port, mind egyetlen hálózati névtéren belül. Egy UDP-hallgató és egy TCP-hallgató ugyanazon a számon különböző socketek, és két folyamat ugyanazon a számon különböző névterekben soha nem találkozik.

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

Először azt a szállítást futtassa, amelyet a profil valóban használ. Utána nézze meg a helyi cím oszlopát, ne csak a számot: egy wildcard kötés minden helyi címet lefed, így egy második folyamat, amely egy adott címet kér, ütközhet vele, még ha a kiírt karakterláncok eltérnek is. A socket-újrafelhasználási beállítások és a platformszabályok döntik el a pontos eredményt, ezért ennek megfigyelésnek kell lennie, nem pedig minden telepítésre alkalmazott szabálynak.

Találja meg, melyik folyamat birtokolja

A numerikus végpontok és a folyamatinformációk azonosítják a tulajdonost, ha a jogosultságai engedik, és a tulajdonos az, amire szüksége van, nem a program neve. Két OpenVPN-folyamat különböző profilokat futtathat, és az, amelyik a hallgatót tartja, lehet a legkevésbé várt.

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

Hasonlítsa össze, amit talál, a szolgáltatáskezelővel, egy konténer-futtatókörnyezettel vagy egy korábbi tesztből visszamaradt terminálfolyamattal. A folyamat részleteinek hiánya nem bizonyítja, hogy a socketnek nincs tulajdonosa; általában azt jelenti, hogy a lekérdezés nem elegendő jogosultsággal futott. Ugyanígy a csak TCP-t tartalmazó lista nem oszlatja el az UDP-ütközést, ezért vizsgálja meg a hibában megnevezett szállítást. Egy folyamatnév önmagában soha nem mondja meg, melyik profil töltődött be, és a profil az, ami a végpontot meghatározza.

Egy tulajdonos, vagy két tervezett példány

Ha a telepítés egy kiszolgálót szán, tartson egy életciklus-tulajdonost, és olvassa az adott példány naplóját vagy a beállított logot ahelyett, hogy egy második példányt indítana a megfigyeléséhez. Amikor egy ellenőrzött előtérbeli futtatás valóban szükséges, állítsa le szándékosan a kezelt példányt, és előtte vegye figyelembe az általa kiszolgált ügyfeleket.

Ha két példányt terveznek, adjon nekik külön hallgatókat és külön mindent: címpoolokat, virtuális interfészeket, útválasztási szabályzatot és konfigurációtulajdont. Egy eltérő port önmagában csak a socketet választja el, és a két kiszolgáló továbbra is ugyanazért a poolért és ugyanazokért az útvonalakért küzd.

Három rövidítést érdemes megnevezni, mert minden ezzel a hibával foglalkozó beszélgetésben megjelennek. Ne öljön meg egy tetszőleges PID-et, amely a bűnösnek tűnik. Ne engedélyezze a socket megosztását az üzenet elhallgattatásához. Ne váltson egy kiszolgálóprofilt kliensstílusú, nem kötött konfigurációra, mert az eltünteti a kötési hibát; a kiszolgáló elérhetetlenné válik olyan módon, amelyet nehezebb diagnosztizálni, mint az eredeti ütközést.

A port megváltoztatása csak akkor jogszerű válasz, ha az új hallgató egy jóváhagyott tervezés része, amely tartalmazza a továbbítási szabályt és az ügyfél végpontját. Ha ezeket nem frissítették, az ütközést olyan helyre helyezte át, ahol senki nem találja meg.

Ellenőrizze a kötést mindenek előtt

A korlátozott javítás után erősítse meg, hogy a szánt példány aktív, hogy hallgatója a várt szállításon jelenik meg, és hogy egy ügyfél csatlakozni tud. A sikeres kötés csak a helyi socket szakaszt fejezi be; semmit nem igazol az azonosításról vagy a forgalomról, miután az alagút felállt.

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

Ha a socket jelen van, és az ügyfél továbbra is meghiúsul, a fennmaradó probléma lejjebb van, és a kötési hiba immár történelem. Ez a szétválasztás a lényege annak, hogy először a pontos üzenetet olvassa el: egy hiba, egy réteg, egy tulajdonos. Így olvassa, és a következő tünet ismert állapotból indul, nem találgatásból.