FortiClient zawiesza się na 98%: wyłącz IPv6 na tym adapterze

Pasek dochodzi do 98%, klient tam stoi, a ponowne wpisanie hasła niczego nie zmienia. To jest użyteczna wskazówka: klient już zaakceptował certyfikat bramy, wysłał poświadczenia i otrzymał konfigurację tunelu. Pozostaje podnieść wirtualny adapter i potwierdzić, że tunel przenosi ruch. Gdy ten ostatni krok nigdy się nie kończy, usterka jest lokalna i żadne ponowne wpisywanie poświadczeń do niej nie dociera.

Cztery kroki, a pierwszy to czytanie dziennika, a nie paska.

Co tak naprawdę raportuje licznik 98%

Procent to własny licznik etapów klienta, a nie miara przepustowości. Zawieszenie na tej samej liczbie przy każdej próbie oznacza, że klient dociera do określonego etapu i czeka; dlatego wolne połączenie i zawieszony klient wyglądają w dzienniku inaczej. Problem z poświadczeniami wypisałby błąd poświadczeń zamiast cichej pauzy.

Fortinet udokumentował ten objaw wobec jednej przyczyny po stronie klienta: włączonego IPv6 na adapterze, którego używa klient. To czyni ustawienie adaptera pierwszą rzeczą do sprawdzenia, a nie uniwersalnym wyjaśnieniem każdego SSL-VPN zawieszenia.

Krok 1: przeczytaj dziennik przed paskiem

Zanim cokolwiek zmienisz, przechwyć wiersze bezpośrednio przed zawieszeniem. Szukasz informacji, czy utworzono adapter tunelu, czy przydzielono adres i czy klient przestał czekać na rodzinę adresów. Zawieszenie na innym procencie to inny etap z własną diagnostyką, a ostrzeżenie o certyfikacie lub błędny adres bramy daje własny komunikat zamiast cichego oczekiwania. Zapisz znacznik czasu, ponieważ następna próba dopisze kolejny blok do tego samego pliku.

Jeśli dziennik pokazuje ukończone logowanie, po którym nic nie następuje, jesteś w konfiguracji lokalnej, a adapter jest uzasadnionym podejrzanym.

Krok 2: ogranicz zmianę IPv6 do jednego adaptera

Zmiana należy do adaptera, nie do maszyny. We właściwościach adaptera w Windows oznacza to odznaczenie Internet Protocol Version 6 (TCP/IPv6) na konkretnym interfejsie, a z powłoki to Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Potwierdź stan za pomocą Get-NetAdapterBinding -ComponentID ms_tcpip6 przed ponownym połączeniem. Następnie połącz się ponownie i sprawdź, czy pasek przekracza 98%, zamiast się na nim zatrzymywać.

Najpierw ogranicz zakres, potem testuj. Globalne wyłączenie IPv6 to większa zmiana, niż wymaga pytanie, i wpływa na usługi, których nie zamierzałeś ruszać.

Krok 3: sprawdź, co ukrywało zawieszenie

Tunel, który się łączy, nie jest tunelem, który działa. Sprawdź adres przydzielony przez klienta, trasy zainstalowane przez profil i rozwiązywanie nazw dla jednego hosta wewnętrznego: Resolve-DnsName files.corp.example. Klient, który się łączy i niczego nie rozwiązuje, ma problem z DNS, a to łatwo odczytać błędnie jako powrót tej samej usterki.

Przetestuj jeden zasób wewnętrzny po nazwie i jeden cel publiczny, aby zepsuty tunel dzielony nie został wzięty za naprawionego klienta.

Krok 4: uczynić poprawkę powtarzalną

Jeśli ustawienie ma dotrzeć do całej floty, umieść je w pakiecie wdrożeniowym lub w konfiguracji adaptera, a nie w ręcznym kroku powtarzanym na każdym laptopie. Zapisz w zgłoszeniu, że zawieszenie na 98% było związane z IPv6 na interfejsie sieciowym, i zaznacz, co jeszcze na hoście zależało od IPv6, zanim ktoś włączy je ponownie, aby naprawić coś niezwiązanego.

Poprawka, która istnieje tylko w pamięci jednego inżyniera, to poprawka, która wróci w następnym kwartale.

Jeśli pasek nadal zatrzymuje się na 98% przy wyłączonym IPv6, notatka producenta już tego nie wyjaśnia, a dziennik jest twoim następnym dowodem. Przestań leczyć objaw i wróć do licznika etapów.