A FortiClient 98%-nál megakad: kapcsolja ki az IPv6-ot azon az adapteren

A sáv eléri a 98%-ot, a kliens ott marad, és a jelszó újragépelése semmin sem változtat. Ez a hasznos nyom: a kliens már elfogadta az átjáró tanúsítványát, elküldte a hitelesítő adatokat és megkapta az alagút konfigurációját. Ami marad: a virtuális adapter felhozatala és annak megerősítése, hogy az alagút továbbítja a forgalmat. Amikor ez az utolsó lépés soha nem fejeződik be, a hiba helyi, és a hitelesítő adatok újragépelése nem ér el odáig.

Négy lépés, és az első a napló olvasása a sáv helyett.

Mit jelent valójában a 98%-os számláló

A százalék a kliens saját fázisszámlálója, nem az átviteli sebesség mértéke. Ha minden kísérletnél ugyanannál a számnál akad meg, a kliens elér egy adott lépést és vár; ezért néz ki másképp a naplóban egy lassú kapcsolat és egy megakadt kliens. Hitelesítő adatok problémája hitelesítési hibát írna ki csendes szünet helyett.

A Fortinet ezt a tünetet egyetlen kliensoldali okhoz kötötte: az IPv6 be van kapcsolva azon az adapteren, amelyet a kliens használ. Ezért az adapterbeállítás az első dolog, amit tesztelni kell, nem pedig minden SSL-VPN megakadás egyetemes magyarázata.

1. lépés: a naplót olvassa a sáv előtt

Mielőtt bármit módosítana, rögzítse a megakadás előtti sorokat. Azt keresi, létrejött-e az alagút-adapter, kapott-e címet, és feladta-e a kliens egy címcsaládra való várakozást. Egy másik százaléknál való megakadás más fázis, saját diagnózissal, a tanúsítványfigyelmeztetés vagy a rossz átjárócím pedig a saját üzenetét adja csendes várakozás helyett. Jegyezze fel az időbélyeget, mert a következő kísérlet újabb blokkot fűz ugyanahhoz a fájlhoz.

Ha a napló befejezett bejelentkezést mutat, utána pedig semmit, akkor helyi beállításban van, és az adapter jogos gyanúsított.

2. lépés: szűkítse az IPv6-változtatást egyetlen adapterre

A változtatás az adapterhez tartozik, nem a géphez. A Windows adaptertulajdonságaiban ez az Internet Protocol Version 6 (TCP/IPv6) törlését jelenti az adott interfészen, héjból pedig ez: Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Erősítse meg az állapotot ezzel: Get-NetAdapterBinding -ComponentID ms_tcpip6, mielőtt újracsatlakozik. Utána csatlakozzon újra, és figyelje, hogy a sáv átlépi-e a 98%-ot ahelyett, hogy megállna rajta.

Először szűkítse a hatókört, aztán teszteljen. Az IPv6 globális kikapcsolása nagyobb változtatás, mint amit a kérdés megkíván, és olyan szolgáltatásokat érint, amelyeket nem akart megérinteni.

3. lépés: ellenőrizze, mit rejtett a megakadás

Egy csatlakozó alagút még nem működő alagút. Ellenőrizze a kliens által kiosztott címet, a profil által telepített útvonalakat és egy belső gazdagép névfeloldását: Resolve-DnsName files.corp.example. Az a kliens, amely csatlakozik és semmit nem old fel, DNS-problémával küzd, és ezt könnyű félreolvasni úgy, hogy ugyanaz a hiba tért vissza.

Teszteljen egy belső erőforrást név szerint és egy nyilvános célt, hogy a törött megosztott alagutat ne nézzék javított kliensnek.

4. lépés: tegye ismételhetővé a javítást

Ha a beállításnak el kell jutnia egy flottához, tegye a telepítési csomagba vagy az adapter konfigurációjába, ne egy minden laptopon megismételt kézi lépésbe. Jegyezze fel a ticketbe, hogy a 98%-os megakadás az IPv6-hoz kapcsolódott a hálózati interfészen, és írja le, mi más függött a gazdagépen az IPv6-tól, mielőtt valaki újra bekapcsolja valami független dolog javításához.

Az a javítás, amely csak egy mérnök emlékezetében létezik, a következő negyedévben visszatérő javítás.

Ha a sáv kikapcsolt IPv6 mellett is 98%-nál áll meg, a szállítói megjegyzés már nem magyarázza, és a napló a következő bizonyítéka. Ne a tünetet kezelje, hanem térjen vissza a fázisszámlálóhoz.