Az OpenVPN TLS-hiba után újra és újra próbálkozik: hogyan állítsuk le

A kliens csatlakozik, a TLS-tárgyalás során meghiúsul, vár, majd ugyanazzal az eredménnyel újra megpróbálja ugyanazt a szervert. Egy felügyelő alatt, amely újraindítja a meghiúsult folyamatot, ezek a kísérletek végtelen hurokká válnak a naplóban, és az első diagnosztikai sor kicsúszik a látótérből. Az OpenVPN kínál egy beállítást, amely ezt a tárgyalási hibát látható kilépéssé alakítja egy újabb próbálkozás helyett. Ez diagnosztikai és felügyeleti beállítás, nem javítás, ezért párosítsa olyan szabályzattal, amely valóban lent hagyja a folyamatot.

A ciklus, amely elrejti az első hibát

Amit lát, az egy ismétlődő blokk, nem egyetlen hiba: kapcsolódási kísérlet, TLS-hiba, szünet, majd ugyanaz a sorrend. Minden ismétlés feljebb tolja az eredeti sort a naplóban. Ha az egység hiba esetén újraindul, a ciklus órákig folytatódhat, anélkül hogy bárki elolvasná az okot. A tünet a hurok, pedig a mögöttes hiba egyetlen tárgyalási probléma.

Az interaktív munkamenetek elviselik ezt, mert egy átmeneti hiba elmúlhat a következő próbálkozásra. Az automatizált kapcsolatok nem engedhetik meg maguknak ugyanezt az optimizmust: a folyamatnak meg kell állnia, hogy egy ember vagy egy monitor lássa az állapotot.

Mielőtt bármit megváltoztat, rögzítsen egy teljes ciklust. Jegyezze fel a távoli címet, a hibában megnevezett TLS-szakaszt és azt, hogy a folyamat egyáltalán kilép-e.

A hurok mögötti újrapróbálkozási mechanizmus

Az újrapróbálkozás az alapértelmezés, mert több egymástól független időtúllépés ugyanazt a mechanizmust használja. A connect-retry állítja be a kapcsolódási kísérletek közötti különbséget, a connect-retry-max korlátozhatja, milyen gyakran próbálkozik az egyes távoli bejegyzésekkel, a resolv-retry pedig az ismételt névkereséseket szabályozza. A TLS-tárgyalás hibája szállítási eseményként éri el ezt a mechanizmust, ezért a kliens jelentés helyett újabb kísérletet ütemez. Az alapértelmezés segít instabil kapcsolatnál, és árt olyan hibánál, amely nem tud meggyógyulni.

A --tls-exit beállítás csak a tárgyalási esetet változtatja meg. A kézikönyv úgy írja le, mint kilépést TLS-tárgyalási hiba esetén, ami szűkebb, mint minden hibánál kilépni. Az időtúllépések, a feloldó hibái és a hitelesítési elutasítások megtartják saját viselkedésüket.

Késztesse a klienst kilépésre TLS-hiba esetén

Tegye a tls-exit beállítást abba a profilba, amelyet a kliens valóban betölt, vagy adja meg a --tls-exit beállítást indításkor, és futtassa egyszer előtérben. Olvassa ki a kilépési állapotot és az utolsó naplósort is, mert a felügyelő az állapotra reagál. A nem nulla kilépés tárgyalási hiba után a kívánt eredmény. Ha a folyamat befejezés helyett tovább próbálkozik, a beállítás nincs abban a profilban, amelyet a kliens valóban betölt.

A felügyelő dönti el, hogy az a kilépés látható-e. Egy systemd-egység Restart=always vagy Restart=on-failure beállítással újraindítja a klienst, így a hurok folytatódik, és a beállítás úgy tűnik, mintha semmit sem tenne. Ellenőrizze a szabályzatot, mielőtt a klienst hibáztatná:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

A Restart=no lent hagyja a folyamatot, a Restart=on-failure pedig nem nulla állapot után is újraindít. Ha azt szeretné, hogy a hiba látható legyen, de a szolgáltatás felépüljön a független összeomlásokból, állítsa be a Restart=on-failure beállítást, és használja a StartLimitBurst és StartLimitIntervalSec beállítást az újraindítási vihar megállítására. Ezután olvassa ki az egység állapotát az utolsó kilépési kód megerősítéséhez: a systemctl status jelenti azt, és a napló megtartja az első hibát az újraindítások fölött.

Írja le a döntést az egységbe vagy a profil megjegyzéseibe. Egy profil, amely TLS-hiba esetén kilép, balesetnek tűnik a következő ember számára, hacsak az ok nincs rögzítve. Adja meg, mely hibák állítsák le a folyamatot, és melyeket kell újrapróbálni.

Bizonyítsa egy eldobható végponttal

Hogy lássa a viselkedést, mielőtt megbízik benne, másolja le a profilt, és irányítsa a másolatot egy olyan végpontra, amely elfogad egy TCP-kapcsolatot, de soha nem beszél OpenVPN-t. Elég egy hallgató, amely válaszol, majd hallgat. A tls-exit beállítással a kliensnek akkor kell véget érnie, amikor a kézfogás meghiúsul; enélkül ugyanannak a profilnak tovább kell köröznie. A másolatot használja, soha a működő profilt.

Hasonlítsa össze a két futást a kilépési állapot és az első hiba sor alapján, ne az alapján, mennyi ideig tartottak. Az állapot megmondja, hogy a beállítás működött-e, az első sor pedig azt, melyik szakasz hibázott.

Távolítsa el a tesztprofilt, amikor végzett. A szándékosan rossz végponttal rendelkező másolat csapda mindenkinek, aki később a könyvtár összes profilját elindítja.

Szakaszok, amelyeket ez a beállítás soha nem ér el

A hitelesítési elutasítás későbbi szakasz. Ha a szerver értékeli a fiókot, és elutasítja, a TLS már megtárgyalódott, ezért a tls-exit nem lép működésbe. A hitelesítés újrapróbálkozási beállításai a következő hely, ahol keresni kell, és a szerver indoka fontosabb, mint a kliens utolsó sora. Egy rossz jelszó és egy hiányzó tanúsítvány hasonló üzeneteket okozhat a kliens oldalán.

A hiányzó útvonal, a rossz feloldó vagy az elérhetetlen átjáró szintén a beállításon kívül esik, mert nem tárgyalási hibák. A csendes csomagvesztés a legkevésbé nyilvánvaló eset: attól függően, meddig jutott a csere, a kliens tárgyalási hibát jelenthet, vagy egyszerűen időtúllépésbe fut.

Tartsa meg a különbségtételt a jegyzeteiben. A beállítás diagnosztikára és felügyeletre szolgál, nem javításra, ezért nem javítja a titkosítási eltérést, a tanúsítványproblémát vagy a rossz portot. Először a meghiúsult tárgyalás okát javítsa, majd döntse el, hogy az azonnali kilépés még megfelel-e az üzembe helyezésnek.