FortiClient se blochează la 98%: dezactivați IPv6 pe acel adaptor

Bara ajunge la 98%, clientul rămâne acolo, iar rescrierea parolei nu schimbă nimic. Acesta este indiciul util: clientul a acceptat deja certificatul gateway-ului, a trimis credențialele și a primit o configurație de tunel. Ce rămâne este să ridice adaptorul virtual și să confirme că tunelul transportă trafic. Când acel ultim pas nu se finalizează niciodată, defectul este local, iar nicio rescriere de credențiale nu ajunge la el.

Patru pași, iar primul este citirea jurnalului, nu a barei.

Ce raportează de fapt contorul de 98%

Procentul este contorul de etape al clientului însuși, nu o măsură a debitului. Un blocaj la același număr la fiecare încercare înseamnă că clientul ajunge la o etapă anume și așteaptă; de aceea o conexiune lentă și un client blocat arată diferit în jurnal. O problemă de credențiale ar tipări o eroare de credențiale în locul unei pauze silențioase.

Fortinet a documentat acest simptom față de o singură cauză din partea clientului: IPv6 activat pe adaptorul pe care îl folosește clientul. Asta face din setarea adaptorului primul lucru de testat, nu o explicație universală pentru fiecare SSL-VPN blocaj.

Pasul 1: citiți jurnalul înaintea barei

Înainte de a schimba ceva, capturați liniile imediat dinaintea blocajului. Căutați dacă adaptorul de tunel a fost creat, dacă a fost atribuită o adresă și dacă clientul a renunțat să aștepte o familie de adrese. Un blocaj la alt procent este o altă etapă cu diagnosticul ei, iar un avertisment de certificat sau o adresă de gateway greșită produce propriul mesaj în locul unei așteptări silențioase. Notați marcajul temporal, pentru că următoarea încercare adaugă un alt bloc în același fișier.

Dacă jurnalul arată o autentificare finalizată urmată de nimic, sunteți în configurarea locală, iar adaptorul este un suspect legitim.

Pasul 2: limitați schimbarea IPv6 la un singur adaptor

Schimbarea aparține adaptorului, nu mașinii. În proprietățile adaptorului din Windows asta înseamnă să debifați Internet Protocol Version 6 (TCP/IPv6) pe interfața respectivă, iar dintr-un shell este Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Confirmați starea cu Get-NetAdapterBinding -ComponentID ms_tcpip6 înainte de a vă reconecta. Apoi reconectați-vă și urmăriți dacă bara trece de 98% în loc să se oprească acolo.

Mai întâi delimitați, apoi testați. Dezactivarea IPv6 la nivel global este o schimbare mai mare decât cere întrebarea și afectează servicii pe care nu intenționați să le atingeți.

Pasul 3: verificați ce ascundea blocajul

Un tunel care se conectează nu este un tunel care funcționează. Verificați adresa atribuită de client, rutele instalate de profil și rezolvarea numelor pentru un host intern: Resolve-DnsName files.corp.example. Un client care se conectează și nu rezolvă nimic are o problemă DNS, iar asta se citește ușor greșit ca întoarcerea aceluiași defect.

Testați o resursă internă după nume și o destinație publică, ca un tunel divizat stricat să nu fie confundat cu un client reparat.

Pasul 4: faceți remedierea repetabilă

Dacă setarea trebuie să ajungă la o flotă, puneți-o în pachetul de implementare sau în configurația adaptorului, nu într-un pas manual repetat pe fiecare laptop. Notați în tichet că blocajul la 98% era legat de IPv6 pe interfața de rețea și ce altceva de pe host depindea de IPv6 înainte ca cineva să îl reactiveze pentru a repara ceva nelegat.

O remediere care există doar în memoria unui inginer este o remediere care revine trimestrul următor.

Dacă bara se oprește în continuare la 98% cu IPv6 dezactivat, nota furnizorului nu mai explică asta, iar jurnalul este următoarea dumneavoastră dovadă. Opriți tratarea simptomului și reveniți la contorul de etape.