FortiClient blijft hangen op 98%: schakel IPv6 uit op die adapter

De balk bereikt 98%, de client blijft daar staan, en het wachtwoord opnieuw intypen verandert niets. Dat is de nuttige aanwijzing: de client heeft het gateway-certificaat al geaccepteerd, inloggegevens verzonden en een tunnelconfiguratie ontvangen. Wat overblijft, is de virtuele adapter opzetten en bevestigen dat de tunnel verkeer draagt. Wanneer die laatste stap nooit voltooit, is de fout lokaal, en geen enkele hoeveelheid opnieuw ingevoerde inloggegevens bereikt hem.

Vier stappen, en de eerste is de log lezen in plaats van de balk.

Wat de teller van 98% werkelijk meldt

Het percentage is de eigen fasenteller van de client, geen maat voor doorvoer. Een hapering bij hetzelfde getal bij elke poging betekent dat de client een bepaalde fase bereikt en wacht; daarom zien een trage verbinding en een vastgelopen client er anders uit in de log. Een probleem met inloggegevens zou een fout over de gegevens afdrukken in plaats van een stille pauze.

Fortinet documenteerde dit symptoom tegen één oorzaak aan de clientzijde: IPv6 ingeschakeld op de adapter die de client gebruikt. Dat maakt de adapterinstelling het eerste dat getest moet worden, geen universele verklaring voor elke SSL-VPN hapering.

Stap 1: lees de log vóór de balk

Voordat u iets wijzigt, legt u de regels vlak voor de hapering vast. U zoekt of de tunneladapter is aangemaakt, of er een adres is toegewezen en of de client is gestopt met wachten op een adresfamilie. Een hapering bij een ander percentage is een andere fase met zijn eigen diagnose, en een certificaatwaarschuwing of een verkeerd gateway-adres levert zijn eigen bericht in plaats van een stil wachten. Noteer de tijdstempel, want de volgende poging voegt nog een blok aan hetzelfde bestand toe.

Als de log een voltooide aanmelding toont en daarna niets, zit u in de lokale configuratie en is de adapter een legitieme verdachte.

Stap 2: beperk de IPv6-wijziging tot één adapter

De wijziging hoort bij de adapter, niet bij de machine. In de Windows-adaptereigenschappen betekent dat Internet Protocol Version 6 (TCP/IPv6) uitvinken op de specifieke interface, en vanuit een shell is het Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Bevestig de status met Get-NetAdapterBinding -ComponentID ms_tcpip6 voordat u opnieuw verbindt. Verbind daarna opnieuw en kijk of de balk 98% voorbijgaat in plaats van daar te stoppen.

Beperk eerst, test dan. IPv6 wereldwijd uitschakelen is een grotere wijziging dan de vraag vereist en het raakt diensten die u niet wilde aanraken.

Stap 3: controleer wat de hapering verborgen hield

Een tunnel die verbindt is geen tunnel die werkt. Controleer het adres dat de client toewees, de routes die het profiel installeerde, en naamresolutie voor één interne host: Resolve-DnsName files.corp.example. Een client die verbindt en niets oplost, heeft een DNS-probleem, en dat is gemakkelijk verkeerd te lezen als dezelfde fout die terugkeert.

Test één interne bron op naam en één openbare bestemming, zodat een kapotte split-tunnel niet voor een gerepareerde client wordt aangezien.

Stap 4: maak de oplossing herhaalbaar

Als de instelling een vloot moet bereiken, zet hem dan in het implementatiepakket of in de adapterconfiguratie in plaats van in een handmatige stap die op elke laptop wordt herhaald. Noteer in het ticket dat de hapering bij 98% samenhing met IPv6 op de netwerkinterface, en noteer wat er verder op de host van IPv6 afhing voordat iemand het weer inschakelt om iets ongerelateerds te repareren.

Een oplossing die alleen in het geheugen van één engineer bestaat, is een oplossing die volgend kwartaal terugkomt.

Als de balk met IPv6 uit nog steeds bij 98% stopt, verklaart de leveranciersnotitie het niet meer en is de log uw volgende bewijs. Stop met het behandelen van het symptoom en ga terug naar de fasenteller.