Óránkénti OpenVPN-megszakadás: újratárgyalás vagy valódi újracsatlakozás?

Hatvan perc, vagy harminc, vagy százhúsz: a kerek intervallumra eső megszakadás szinte soha nem a hálózat. OpenVPN időzítő szerint frissíti az adatcsatornát védő kulcsanyagot, és a feltételezettnél rövidebb időzítő pontosan úgy néz ki, mint egy folyton megszakadó kapcsolat. A felhasználók szakadt kapcsolatról számolnak be, miközben a napló sikeres kulcscseréről. Az alábbi útmutató elválasztja ezt a frissítést a valódi újraindítástól, kiolvassa a ténylegesen érvényes értéket, és csak aztán változtat rajta, hogy a költség az asztalra került.

A lépéseket sorrendben végezze el, mert az első dönti el, hogy az oldal többi része egyáltalán vonatkozik-e Önre. Ha előreszalad, egy estét azzal tölt, hogy egy olyan hiba miatt hangoljon időzítőt, amelynek semmi köze hozzá.

Különböztesse meg a lágy visszaállítást az újraindítástól

A naplósor a teljes diagnózis. Az újratárgyalás lágy visszaállítást ír, majd friss kulcscserét ugyanazon az alagúton belül: az interfész megtartja a címét, az útvonalak nem kerülnek újra hozzáadásra, és a létrejött TCP-munkamenetek általában szünettel túlélik. A valódi újraindítás szétszakítja a munkamenetet, újraépíti az interfészt, esetleg más ügyfélcímet oszt ki, és minden hosszú életű kapcsolatot megöl. Mindkét esemény mindennapos; csak az egyik magyarázza a megszakadt hívást.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

A verziósor azért fontos, mert a napló megfogalmazása kiadások között változik, és egy 2.3-ból ismert üzenet 2.6-ban másképp fogalmazódhat. A saját naplóját olvassa, ne egy fórumrészletet valaki másétól. Segítségkéréskor a pontos sort idézze, mert a körülírás elveszti azt a részletet, amely az eseményt azonosítja. Ha az interfész címe az esemény alatt változatlan, és a munkamenet-lista túléli, frissítést lát, és a többi szakasz érvényes.

Az érvényes időzítőt olvassa, ne a fájlját

reneg-sec az adatcsatorna újratárgyalásai közötti másodpercek száma, alapértéke 3600. Mindkét fél a saját értékét hordozza, és a kettő közül a kisebb az, amely ténylegesen kiváltja a frissítést. Ez az egyetlen szabály magyarázza a jelentések többségét: a nagy számot beállító ügyfélprofil is óránként visszaáll, amíg a kiszolgáló az alapértéket tartja.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Olvassa el a kiszolgáló érvényes konfigurációját is, beleértve mindazt, amit továbbít, mielőtt az ügyfélfájlból következtetést vonna. Ezután növelje a részletességet, és kövessen végig egy intervallumot: a 3-as szint már mutatja az újratárgyalás sorait, és az időbélyegek megmondják, hogy az esemény 3600 másodpercenként ismétlődik, vagy inkább a tevékenységet követi.

Ott változtassa meg, ahol valóban továbbítják

A keringő gyógymód egyetlen sor az ügyfélprofilban, és az esetek körülbelül felében rossz helyen van. Mivel a fél kisebb értéke nyer, egy nullára állított időzítőjű ügyfelet egy változatlan kiszolgáló is újratárgyalhat.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Ahol a profilokat központilag állítják elő, a sablont szerkessze, ne a telepített példányt, különben a következő előkészítési futás visszaállítja az éppen eltávolított értéket. Két intervallum megfigyelésével ellenőrizze, ne eggyel: egyetlen csendes óra összeegyeztethető egy 7200-ra állított időzítővel is.

Döntse el azt is, mi történik vegyes telepítésnél. Ha a változást először az ügyfelekre terjeszti ki, marad egy ablak, amelyben a kiszolgáló még kiváltja a frissítést; ez ártalmatlan, de zavaró, ha a naplókat figyeli megerősítésért. Először a kisebb értékű oldalt változtassa meg, és a tünet eltűnik azon a ponton, amelyet vár.

Miről mond le az újratárgyalás kikapcsolásával

A rendszeres újratárgyalás korlátozza, hogy egyetlen adatcsatorna-kulcskészlet mennyi ideig védi a forgalmat. Az időzítő kikapcsolása nem töri el az alagutat, és otthoni routeren vagy kis irodai átjárón a gyakorlati kitettség szerény. Ez mégis csere, és a cserét érdemes kimondani, mielőtt megteszi. Ami változik, az az, hogy egy kulcskészlet mennyi ideig véd egy munkamenetet, nem az, hogy az alagút egyáltalán működik-e.

A kikapcsolás ésszerű esete egy olyan visszaállítás, amely valami folytathatatlant tör el: megszakadó hívás, újra felállítandó távoli asztali munkamenet, elölről induló biztonsági mentés. Ha a szünet a felhasználók számára láthatatlan, az alapérték megtartása semmibe sem kerül, és megőrzi a kapott kulcsrotációt.

Inkább az okot javítsa, amikor a minta engedi. Az a frissítés, amely félúton meghiúsul, miközben az első kézfogás sikerült, az útra mutat, nem az időzítőre: keressen csomagméret-problémát a nagyobb vezérlőcsatorna-cserében, a folyamot eldobó állapottartó tűzfalat, vagy olyan javaslatot, amely csak első próbára sikerül. Mindegyik nyomot hagy ugyanabban a naplóban, amelyet éppen olvasott. Az időzítő kikapcsolása elrejti ezt a bizonyítékot.

Amikor az intervallum másfelé mutat

Két szomszéd a konfigurációban hasonló tüneteket és eltérő javításokat ad. A ping-restart újraindítja az alagutat, ha egy beállított ideig semmi sem érkezik, míg a ping-exit teljesen leállítja az ügyfelet. A naplóban sehol nem szereplő újratárgyalás nélküli tétlen megszakadás ezekhez tartozik, vagy egy NAT-eszközhöz, amely saját ütemterve szerint járatta le az UDP-leképezést.

A fogyasztói routerek, a mobil hotspotok és az operátori szintű NAT mind lejáratják a tétlen UDP-munkameneteket anélkül, hogy szólnának bárkinek. Ez a hiba a tétlenséget követi, nem az órát, és ez a nyom: az a munkamenet, amely tíz csendes perc után megszakad, és egy óra egyenletes forgalmat túlél, nem tárgyal újra.

Írjon le három dolgot, mielőtt a negyediket megváltoztatja: a mért intervallumot, a talált érvényes értéket és a parancsot, amely megmutatta. Ha az intervallum mozdul, amikor az időzítő mozdul, a mechanizmus azonosított, és a javítás a fenti cseréről szóló döntés. Ha nem mozdul, tegye vissza a beállítást, és továbbra is figyelje a keepalive-okat, a NAT állapotát és a csomagvesztést.