FortiClient fastnar på 98 %: stäng av IPv6 på den adaptern

Stapeln når 98 %, klienten blir sittande, och att skriva lösenordet igen ändrar ingenting. Det är den användbara ledtråden: klienten har redan accepterat gatewayens certifikat, skickat inloggningsuppgifter och fått en tunnelkonfiguration. Det som återstår är att resa den virtuella adaptern och bekräfta att tunneln bär trafik. När det sista steget aldrig slutförs är felet lokalt, och ingen mängd ny inmatning av inloggningsuppgifter når det.

Fyra steg, och det första är att läsa loggen i stället för stapeln.

Vad 98 %-räknaren egentligen rapporterar

Procentsatsen är klientens egen stegräknare, inte ett mått på genomströmning. Ett stopp vid samma siffra vid varje försök betyder att klienten når ett visst steg och väntar; därför ser en långsam anslutning och en fastnad klient olika ut i loggen. Ett problem med inloggningsuppgifterna skulle skriva ut ett fel om dem i stället för en tyst paus.

Fortinet dokumenterade detta symptom mot en enda orsak på klientsidan: IPv6 aktiverat på adaptern som klienten använder. Det gör adapterinställningen till det första som bör testas, inte en universell förklaring till varje SSL-VPN stopp.

Steg 1: läs loggen före stapeln

Innan du ändrar något, fånga raderna precis före stoppet. Du letar efter om tunneladaptern skapades, om en adress tilldelades och om klienten gav upp att vänta på en adressfamilj. Ett stopp vid en annan procent är ett annat steg med sin egen diagnos, och en certifikatvarning eller en felaktig gatewayadress ger sitt eget meddelande i stället för en tyst väntan. Skriv ned tidsstämpeln, eftersom nästa försök lägger till ännu ett block i samma fil.

Om loggen visar en slutförd inloggning följd av ingenting befinner du dig i den lokala konfigurationen och adaptern är en legitim misstänkt.

Steg 2: begränsa IPv6-ändringen till en adapter

Ändringen hör till adaptern, inte till datorn. I Windows adapteregenskaper innebär det att avmarkera Internet Protocol Version 6 (TCP/IPv6) på det aktuella gränssnittet, och från ett skal är det Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Bekräfta statusen med Get-NetAdapterBinding -ComponentID ms_tcpip6 innan du ansluter igen. Anslut sedan igen och se om stapeln passerar 98 % i stället för att stanna där.

Avgränsa först, testa sedan. Att stänga av IPv6 globalt är en större ändring än frågan kräver och det påverkar tjänster du inte tänkt röra.

Steg 3: verifiera vad stoppet dolde

En tunnel som ansluter är inte en tunnel som fungerar. Kontrollera adressen klienten tilldelade, de rutter profilen installerade och namnmatchning för en intern värd: Resolve-DnsName files.corp.example. En klient som ansluter och inte matchar något har ett DNS-problem, och det är lätt att felläsa som att samma fel kommer tillbaka.

Testa en intern resurs vid namn och en offentlig destination, så att en trasig delad tunnel inte förväxlas med en reparerad klient.

Steg 4: gör åtgärden upprepbar

Om inställningen måste nå en hel flotta, lägg den i distributionspaketet eller i adapterkonfigurationen i stället för i ett manuellt steg som upprepas på varje bärbar dator. Anteckna i ärendet att stoppet på 98 % hängde samman med IPv6 på nätverksgränssnittet, och notera vad annat på värden som berodde på IPv6 innan någon slår på det igen för att laga något orelaterat.

En åtgärd som bara finns i en ingenjörs minne är en åtgärd som kommer tillbaka nästa kvartal.

Om stapeln fortfarande stannar på 98 % med IPv6 avstängt förklarar leverantörens anteckning det inte längre, och loggen är ditt nästa bevis. Sluta behandla symptomet och gå tillbaka till stegräknaren.