FortiClient henger på 98 %: slå av IPv6 på den adapteren

Stolpen når 98 %, klienten blir sittende, og det å skrive passordet på nytt endrer ingenting. Det er det nyttige sporet: klienten har allerede godtatt gatewayens sertifikat, sendt innloggingsdata og mottatt en tunnelkonfigurasjon. Det som gjenstår, er å reise den virtuelle adapteren og bekrefte at tunnelen bærer trafikk. Når det siste trinnet aldri fullføres, er feilen lokal, og ingen mengde ny innskriving av innloggingsdata når den.

Fire trinn, og det første er å lese loggen fremfor stolpen.

Hva 98 %-telleren egentlig rapporterer

Prosenten er klientens egen trinnteller, ikke et mål på gjennomstrømning. Et stopp på samme tall ved hvert forsøk betyr at klienten når et bestemt trinn og venter; derfor ser en treg tilkobling og en fastlåst klient ulike ut i loggen. Et problem med innloggingsdata ville skrevet ut en feil om dem i stedet for en stille pause.

Fortinet dokumenterte dette symptomet mot én årsak på klientsiden: IPv6 slått på på adapteren klienten bruker. Det gjør adapterinnstillingen til det første som bør testes, ikke en universell forklaring på enhver SSL-VPN stopp.

Trinn 1: les loggen før stolpen

Før du endrer noe, fang linjene rett før stoppet. Du leter etter om tunneladapteren ble opprettet, om en adresse ble tildelt, og om klienten ga opp å vente på en adressefamilie. Et stopp på en annen prosent er et annet trinn med sin egen diagnose, og en sertifikatadvarsel eller en feil gatewayadresse gir sin egen melding i stedet for en stille venting. Skriv ned tidsstempelet, fordi neste forsøk legger til nok en blokk i samme fil.

Hvis loggen viser en fullført innlogging etterfulgt av ingenting, er du i lokal oppsett og adapteren er en legitim mistenkt.

Trinn 2: begrens IPv6-endringen til én adapter

Endringen hører til adapteren, ikke maskinen. I Windows' adapteregenskaper betyr det å fjerne Internet Protocol Version 6 (TCP/IPv6) på det aktuelle grensesnittet, og fra et skall er det Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Bekreft tilstanden med Get-NetAdapterBinding -ComponentID ms_tcpip6 før du kobler til igjen. Koble så til igjen og se om stolpen passerer 98 % i stedet for å stoppe der.

Avgrens først, test så. Å slå av IPv6 globalt er en større endring enn spørsmålet krever, og det påvirker tjenester du ikke hadde tenkt å røre.

Trinn 3: bekreft hva stoppet skjulte

En tunnel som kobler til, er ikke en tunnel som virker. Kontroller adressen klienten tildelte, rutene profilen installerte, og navneoppslag for én intern vert: Resolve-DnsName files.corp.example. En klient som kobler til og ikke løser opp noe, har et DNS-problem, og det er lett å feiltolke som at den samme feilen kommer tilbake.

Test én intern ressurs ved navn og én offentlig destinasjon, så en ødelagt delt tunnel ikke forveksles med en reparert klient.

Trinn 4: gjør rettelsen repeterbar

Hvis innstillingen må ut til en hel flåte, legg den i distribusjonspakken eller i adapterkonfigurasjonen i stedet for i et manuelt trinn som gjentas på hver bærbar. Noter i saken at stoppet på 98 % var knyttet til IPv6 på nettverksgrensesnittet, og noter hva annet på verten som var avhengig av IPv6 før noen slår det på igjen for å rette noe urelatert.

En rettelse som bare finnes i én ingeniørs hukommelse, er en rettelse som kommer tilbake neste kvartal.

Hvis stolpen fortsatt stopper på 98 % med IPv6 av, forklarer leverandørnotatet det ikke lenger, og loggen er ditt neste bevis. Slutt å behandle symptomet og gå tilbake til trinntelleren.