A VPN folyton megszakad? Haladjon végig ezen a sorrenden

Mielőtt újratelepíti a klienst, írjon fel három dolgot: meddig maradt fenn az alagút, mit mondott a kliens a megszakadáskor, és aludt-e vagy hálózatot váltott-e közben a gép. Ez a feljegyzés lesz az egyetlen bizonyíték, amivel később rendelkezik, és az újratelepítés általában törli. Az ismétlődő intervallumú megszakadás időzítő vagy állapotlejárat; a véletlen pillanatban bekövetkező megszakadás útvonalprobléma. Az alábbi sorrend megóvja attól, hogy egyszerre három dolgot módosítson, és semmit ne tanuljon.

Első lépés: rögzítse az intervallumot és a hiba szövegét

A kliens saját naplójával kezdje, ne a szolgáltató irányítópultjával. Linux kliensen a szolgáltatás naplója és az alagút élő állapota a legtöbbet lefedi:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Rögzítse az utolsó sikeres kézfogás időbélyegét és azt a pillanatot, amikor a forgalom megállt, ne csak azt, amikor az ikon színt váltott. Egy GUI kliens, amely utólag jelzi a megszakadást, talán olyan állapotot jelent, amelyet a kernel másodpercekkel korábban ért el.

Tartsa meg a hiba megfogalmazását. Az időtúllépés, a hitelesítés elutasítása és az adapter- vagy illesztőprogram-hiba három különböző rétegre mutat, és ebben a problémában a legtöbb elvesztegetett erőfeszítés abból fakad, hogy egyként kezelik őket. Másolja a sort szó szerint a feljegyzésébe.

Második lépés: egy változót módosítson, ne a profilt

Tartsa rögzítve az eszközt és a profilt, és vigye a gépet másik hozzáférési hálózatra, például telefonos hotspotra. Ez a legolcsóbb teszt, amely elválasztja a klienst az útvonaltól. Futtassa elég sokáig, hogy lefedje az eredeti hiba-intervallumot; két stabil perc semmit sem bizonyít egy harmincadik percben bekövetkező megszakadásról.

Az Ethernet-porttal rendelkező laptop második összehasonlítást ad, amely teljesen kiveszi a Wi-Fi-t a képből. Ha az alagút mindkét alternatíván tart, az eredeti hozzáférési hálózat figyelmet érdemel: hozzáférési pontok közti roaming, lejáró fordítási táblázatú otthoni router, vagy hosszú életű folyamokat visszaállító felső kapcsolat.

Írja fel, melyik változót módosította. Az összehasonlítás csak akkor érvényes, ha minden más ugyanaz maradt, és ez magában foglalja a kiszolgáló végpontját és a napszakot is.

Harmadik lépés: rendelje az intervallumot réteghez

Egy jó munkamenet hossza a leginformatívabb egyetlen szám, amivel rendelkezik. Olvassa össze ezzel a listával, mielőtt az időzítőkhöz nyúlna:

• Megszakadás alvás vagy folytatás után: az alagút állapota túlélte a felfüggesztést, a felület azonban nem. Vizsgálja meg a kliens újracsatlakozási viselkedését folytatáskor, és hogy a szolgáltatás újraindítja-e az alagutat, vagy forgalomra vár.
• Megszakadás csak tétlenség esetén: valami középen lejárt, ami a folyamot lezárta. Pontosan erre az esetre léteznek a keepalive-ok.
• Megszakadás rögzített munkamenet-korban: újrahitelesítési vagy kulcsfrissítési esemény, nem útvonalhiba. A naplóban pontosan abban az intervallumban megjelenő egyértelmű elutasítás a jel.
• Megszakadás nagy átvitelek vagy nagy oldalak közben: gyanakodjon MTU-ra és töredezettségre, ne tétlenségi időzítőre.

A tétlenség esetében a beállítások protokollspecifikusak, és mindkét vég számít. Az OpenVPN keepalive 10 60 beállítása a kiszolgálón 10 másodpercenként pinget küld, és 60 másodperc után újraindítja a kapcsolatot, ha nem érkezik; a NAT mögötti WireGuard kliensek a partnerblokkban PersistentKeepalive = 25 használnak. OpenVPN időzítő szerint újratárgyalja az adatcsatornát is, reneg-sec, amelynek alapértéke 3600 másodperc a 2.x-ben.

Ne másoljon agresszív értékeket egy másik szolgáltató útmutatójából. A rövid időtúllépés veszteséges mobil kapcsolaton éppen azokat a megszakadásokat okozza, amelyeket meg kellett volna akadályoznia, és a kiszolgáló által küldött értékek felülírják a kliensprofilban beállítottakat.

Negyedik lépés: hasonlítson össze egy támogatott alternatívát

Ha az üzemeltető UDP- és TCP-profilt is közzétesz, futtassa ugyanazt az eszközt és hálózatot a másikkal szemben. A tényleges megfelelő fájlt használja, ne a szállítást szerkessze egy másolt profilban. A stabil TCP-profil olyan útvonalon, ahol az UDP visszaáll, arra az útvonalra szűkíti a problémát; nem bizonyítja, hogy a TCP mindenhol a jobb szállítás.

Ugyanez a logika érvényes a végpontokra. Próbáljon ki egy másik kiszolgálót, és tartsa mellette az eredeti eredményt. Ha csak egy kimenet állítja vissza a munkameneteket, az arról a végpontról szóló bizonyíték, nem ok arra, hogy a laptop minden adapterét újraépítse.

Minden váltás után ismételje meg az eredeti kiváltó okot, és erősítse meg, hová megy valójában a forgalom. A visszanyert internet-hozzáférés nem ugyanaz az eredmény, mint az alagúton belüli forgalom, és egy kliens, amely csendben visszaesett egy közvetlen útvonalra, egészségesnek látszik a böngészőből.

Ellenőrizze a javítást, és tartsa meg a visszaállítás lehetőségét

A javítást az eredeti kiváltó ok reprodukálásával ellenőrizzük, nem egy sikeres kapcsolattal. Hagyja az alagutat tétlenül a régi hiba-intervallumon túl, függessze fel és folytassa egyszer, majd ellenőrizze a kézfogás korát és a kimeneti címet:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Tartsa meg az előző profilt és az előző időzítőértékeket, amíg az új viselkedés túlél egy teljes munkanapot. Ha a megszakadások visszatérnek, állítsa vissza a biztonsági mentést, majd ismét egyenként alkalmazza a változtatásokat, hogy a második kísérlet ismert állapotból induljon.

Ha a napló tiszta marad, és az alagút továbbra is ismétlődő intervallumban szakad meg, a következő állomás az adott munkamenet kiszolgálóoldala. Vigye magával a kliens munkamenet-azonosítóját és a megszakadás pontos idejét, mert ez a pár teszi a kiszolgáló naplóját kereshetővé. A protokoll kapcsolati beállításai a OpenVPN 2.6 kézikönyvben dokumentáltak, amikor egy érték pontos jelentésére van szüksége.