Miért tart tovább a VPN helyreállása, mint maga a kiesés

A Wi-Fi harminc másodperce tért vissza, a VPN viszont még mindig nem működik, így az ügyfél hibásnak tűnik. Gyakran csak a saját újrapróbálkozási ütemezését követi, és az az ütemezés nem tudja, hogy a hálózat épp most tért vissza. Ez a rés a teljes történet: a helyreállási idő a kiesés plusz minden várakozás, amelyre az ügyfél már elkötelezte magát. Az összes időzítő csökkentése az egyik válasz, annak megértése pedig a másik, hogy melyik időzítő számít.

Három feltétel dönti el, segít-e a hangolás: melyik szakasz lassú, egyáltalán megismételhető-e a hiba, és hogyan értesül az ügyfél arról, hogy a hálózat visszatért.

Három várakozás, amely egynek látszik

A végpont feloldása, az IKE- vagy TLS-tárgyalás, a csomagok újraküldése és új kísérlet indítása külön események külön időzítőkkel. A strongSwan dokumentálja az újraküldési visszalépkedést az IKE-hez, és az OpenVPN saját újrapróbálkozási vezérlőkkel rendelkezik, más szemantikával. Egy szám átmásolása az egyikből a másikba azt feltételezi, hogy a mechanizmusok megegyeznek, márpedig nem egyeznek. Olvassa el a napló sorrendjét, mielőtt eldönti, melyik intervallumot nézi.

Egy csendes perc a naplóban nem feltétlenül befagyott folyamat. Lehet exponenciális visszalépkedés, amely pontosan azt teszi, amire beállították.

Melyik szakasz lassú valójában?

Ha a napló hitelesítési hibával meghiúsuló kísérleteket mutat, semmilyen időzítő-változtatás nem segít, mert a hitelesítő adat hibás. Ha egyáltalán nem történnek kísérletek, az ügyfél a várakozási ablakában van, és az ütemezés a megoldás. Ha történnek kísérletek és lejárnak, a probléma az elérhetőség vagy egy hiányzó figyelő, és a gyorsabb újrapróbálkozás csak megtölti a naplót. Mindhárom állapotnak más a felelőse, és közülük csak egy időzítési probléma.

Osztályozza a hibát, mielőtt számhoz nyúlna.

Mikor segít az időzítő csökkentése, és mikor nem

Csökkentse az újrapróbálkozás felső határát, ha a domináns költség egy rövid, gyakori kiesés utáni várakozás, például egy hozzáférési pontok között mozgó laptop esetében. Hagyja békén, ha a hibák hosszúak vagy ritkák, mert az agresszív újrapróbálkozás éppen abban a pillanatban ad terhet, amikor a koncentrátor a legkevésbé tud válaszolni. Mindkét esetben változtasson meg egy paramétert, jegyezze fel, és mérje meg a következő helyreállást ahelyett, hogy feltételezné a javulást.

A minden profilba bemásolt nagyon alacsony időtúllépés a mérés nélküli hangolás szokásos végállapota.

Ellenőrizze a készültséget, mielőtt az ügyfelet hibáztatja

Az ügyfél gyakran nem látja, hogy a hálózat használható, amíg valami meg nem próbálja. Egy fogoly portál, egy DHCP-megújítás vagy egy útvonalváltozás olyan ütemezésre várathatja, amelyet mindennek a bekövetkezte előtt állítottak be. Figyelje az operációs rendszer hálózati állapotának változását és az ügyfél következő kísérletét ugyanazon az órán, és látni fogja, kié a várakozás. A gyors változat az, hogy feljegyzi a hálózat-kész esemény időbélyegét és az utána következő első kísérlet időbélyegét.

Erősítse meg azt is, hogy a közvetlen forgalom a várakozás alatt is blokkolva van, mert a forgalmat szivárgó gyorsabb újracsatlakozás nem javulás.

Mit érdemes feljegyezni

Jegyezze fel, melyik időzítő változott, melyik értékről melyikre, és hogyan nézett ki utána a helyreállás. Jegyezze fel az ügyfél verzióját is, mert az alapértékek kiadásról kiadásra mozognak, és egy dokumentálatlan nagyon alacsony időtúllépés összezavarja a profil következő olvasóját.

Ez a feljegyzés a következő szoftverfrissítést összehasonlítássá teszi kísérlet helyett.