A VPN folyton megszakad: előbb a rádiót tesztelje, aztán a szervert

Egy VPN-megszakadás jóval azelőtt elkezdődhet, hogy bármilyen forgalom elérné a szervert. A Wi-Fi elvesztése, a átváltás Wi-Fi-ről mobilhálózatra, a helyi hozzáférési pont torlódása és az elalvó telefon mind megszakíthatja a külső utat, miközben az alagút szoftvere tiszta hibát jelent. Haladjon az eszköztől kifelé: először a kapcsolat, aztán a kliens saját eseményei, aztán egy kontrollált összehasonlítás, és csak utána a szerver. Ez a sorrend megóvja attól, hogy kimeneti csomópontokat cseréljen egy olyan probléma miatt, amely a szobában lakik.

A kapcsolatot figyelje, ne a jelerősség ikonját

Kapcsolatátmeneteket keressen a sávok helyett. Egy eszköz erős jelet mutathat, miközben a hozzáférési pont telített, miközben roaming-átmenet zajlik, vagy miközben egy energiatakarékossági szabályzat leállítja a rádiót kikapcsolt képernyőnél.

Rögzítse az interfész állapotát, az aktuális átjárót és minden változás idejét. Ezután ellenőrizze, hogy a megszakadás egybeesik-e az átmenettel. Az a kiesés, amely minden alkalommal megtörténik, amikor a telefon szobák között mozog, kapcsolati probléma mindaddig, amíg az ellenkezője be nem bizonyosodik, függetlenül attól, melyik szervert mutatja az alkalmazás.

Olvassa el a kliens saját újracsatlakozási eseményeit

A legtöbb kliens naplózza a megszakadás okát és a következő kísérlet időbélyegét. Az az alagút, amely másodperceken belül újratárgyal, majd működik, más esemény, mint amely leállva marad, amíg kézzel be nem kapcsolja.

Az ismétlődő rövid újracsatlakozások a külső útra mutatnak, mert a kliens folyamatosan eléri a szervert és elveszíti a munkamenetet. A leállva maradó alagút hitelesítésre, végpontváltásra vagy szabályzatra mutat, mert a kliens nem jut elég messzire ahhoz, hogy bármit elveszítsen. Olvassa a két mintát külön, mielőtt a konfigurációhoz nyúl.

Óvatosan hasonlítson össze egy második végpontot

Egy második végpont hasznos összehasonlítás, és önmagában nem kontrollált kísérlet. Megváltoztatja az útvonalat, az infrastruktúrát és gyakran az országot, ezért két végpont közötti különbség nem bizonyítja, hogy az első szerver hibás.

Tartsa fixen az eszközt, a hozzáférési hálózatot és a munkaterhelést, és jegyezze fel, mi más változott a váltáskor. Ha mindkét végpont ugyanabban az időben ugyanazon a helyen hibázik, a helyi útvonal a közös tényező. Ha csak az egyik hibázik, a szerver vagy az odavezető útvonal lesz a nyom. Írja le a zavaró tényezőket, hogy a következtetés ne előzze meg a bizonyítékokat.

Korreláljon az Ön által üzemeltetett szerverrel

Ha Ön adminisztrálja a végpontot, egyeztesse a kísérlet idejét a figyelő és az asszociációs naplókkal. Több független kliens hibázása ugyanazon az átjárón más bizonyíték, mint egyetlen telefon kiesése minden mozgásnál.

Egyetlen társválasz nem igazolja az alkalmazás folyamatos egészségét. Helyreállítás után tesztelje az erőforrást, amelyre valóban szüksége van, mert a sikeres kézfogás és az elérhető szerver együtt létezhet egy törött alkalmazásútvonallal.

Írja meg a jelentést, amely leszűkíti

Különítsen el négy állítást: helyi kapcsolatvesztés, külső elérhetőség, alagút-tárgyalás és az alkalmazás saját állapota. Mindegyiknek megvan a maga bizonyítéka, és egy jelentés, amely külön tartja őket, megmondja a következő embernek, hova nézzen.

Jegyezze fel az összehasonlítás korlátait is. Ha egy szabályzat megakadályozta a közvetlen útvonal tesztjét, mondja ezt, ahelyett hogy a végpont-összehasonlítást bizonyítékként mutatná be. Az alkalmazás országcímkéje nem azonosítja a teljes útvonalat, és egy földrajzilag közeli szerver is elérhető lehet egy zsúfolt úton.

A WireGuard-projekt ismert korlátokról szóló oldala hasznos emlékeztető arra, hogy egy protokoll lehet helyes, és a kapcsolat viselkedését mégis az operációs rendszerre hagyhatja. Fejezze be azzal, hogy a következő megszakadás után megismétli ugyanazt a tesztet, mert egyetlen esemény egy adatpont, a minta pedig diagnózis.