FortiClient hang by 98%: skakel IPv6 op daardie adapter af

Die balk bereik 98%, die kliënt sit daar, en om die wagwoord weer te tik verander niks. Dit is die nuttige leidraad: die kliënt het reeds die poort se sertifikaat aanvaar, geloofsbriewe gestuur en 'n tonnelkonfigurasie ontvang. Wat oorbly, is om die virtuele adapter op te bring en te bevestig dat die tonnel verkeer dra. Wanneer daardie laaste stap nooit voltooi nie, is die fout plaaslik, en geen hoeveelheid hertik van geloofsbriewe bereik dit nie.

Vier stappe, en die eerste een is om die logboek te lees eerder as die balk.

Wat die 98%-teller eintlik rapporteer

Die persentasie is die kliënt se eie stadiumteller, nie 'n maatstaf van deurvoer nie. 'n Hang by dieselfde nommer by elke poging beteken die kliënt bereik 'n spesifieke stap en wag, en daarom lyk 'n stadige verbinding en 'n vasgehaakte kliënt anders in die logboek. 'n Geloofsbriefprobleem sou 'n geloofsbriefout druk eerder as 'n stille pouse.

Fortinet het hierdie simptoom gedokumenteer teen een kliëntekant-oorsaak: IPv6 geaktiveer op die adapter wat die kliënt gebruik. Dit maak die adapterinstelling die eerste ding om te toets, nie 'n universele verklaring vir elke SSL-VPN-hang nie.

Stap 1: lees die logboek voor die balk

Voordat jy enigiets verander, vang die reëls onmiddellik voor die hang. Jy soek of die tonneladapter geskep is, of 'n adres toegeken is, en of die kliënt opgegee het om op 'n adresfamilie te wag. 'n Hang by 'n ander persentasie is 'n ander stadium met sy eie diagnose, en 'n sertifikaatwaarskuwing of 'n verkeerde poortadres lewer sy eie boodskap eerder as 'n stille wag. Skryf die tydstempel neer, want die volgende poging voeg nog 'n blok by dieselfde lêer.

As die logboek 'n voltooide aanmelding wys gevolg deur niks, is jy in plaaslike opstelling en is die adapter 'n geldige verdagte.

Stap 2: beperk die IPv6-verandering tot een adapter

Die verandering hoort op die adapter, nie op die masjien nie. In Windows se adaptereienskappe beteken dit om Internet Protocol Version 6 (TCP/IPv6) op die spesifieke koppelvlak te skrap, en vanuit 'n shell is dit Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Bevestig die toestand met Get-NetAdapterBinding -ComponentID ms_tcpip6 voordat jy weer koppel. Koppel dan weer en kyk of die balk 98% verbygaan in plaas daarvan om daar te stop.

Bepaal eers die omvang, toets dan. Om IPv6 globaal te deaktiveer is 'n groter verandering as wat die vraag vereis, en dit raak dienste wat jy nie bedoel het om te raak nie.

Stap 3: verifieer wat die hang verberg het

'n Tonnel wat koppel, is nie 'n tonnel wat werk nie. Kontroleer die adres wat die kliënt toegeken het, die roetes wat die profiel geïnstalleer het, en naamoplossing vir een interne gasheer: Resolve-DnsName files.corp.example. 'n Kliënt wat koppel en niks oplos nie, het 'n DNS-probleem, en dit is maklik om dit verkeerd te lees as dieselfde fout wat terugkeer.

Toets een interne hulpbron by naam en een openbare bestemming, sodat 'n stukkende split-tonnel nie as 'n reggemaakte kliënt misverstaan word nie.

Stap 4: maak die regstelling herhaalbaar

As die instelling 'n vloot moet bereik, sit dit in die ontplooiingspakket of die adapterkonfigurasie eerder as in 'n handmatige stap wat op elke skootrekenaar herhaal word. Teken in die kaartjie aan dat die 98%-hang aan IPv6 op die netwerkkopelvlak gekoppel was, en let op wat anders op die gasheer van IPv6 afhanklik was voordat iemand dit weer aktiveer om iets onverwants reg te maak.

'n Regstelling wat net in een ingenieur se geheue bestaan, is 'n regstelling wat volgende kwartaal terugkom.

As die balk steeds by 98% stop met IPv6 af, verduidelik die verskaffer se nota dit nie meer nie, en die logboek is jou volgende bewys. Hou op om die simptoom te behandel en gaan terug na die stadiumteller.