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

Stolpen når 98 %, klienten blir sitjande, og det å skrive passordet på nytt endrar ingenting. Det er det nyttige sporet: klienten har alt godteke sertifikatet til gatewayen, sendt innloggingsdata og fått ein tunnelkonfigurasjon. Det som står att, er å reise den virtuelle adapteren og stadfeste at tunnelen ber trafikk. Når det siste trinnet aldri blir fullført, er feilen lokal, og ingen mengd ny innskriving av innloggingsdata når han.

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

Kva 98 %-teljaren eigentleg rapporterer

Prosenten er klienten sin eigen trinn teljar, ikkje eit mål på gjennomstrøyming. Eit stopp på same talet ved kvart forsøk betyr at klienten når eit bestemt trinn og ventar; difor ser ei treg tilkopling og ein fastlåst klient ulike ut i loggen. Eit problem med innloggingsdata ville skrive ut ein feil om dei i staden for ei stille pause.

Fortinet dokumenterte dette symptomet mot éin årsak på klientsida: IPv6 slått på på adapteren klienten brukar. Det gjer adapterinnstillinga til det første som bør testast, ikkje ei universell forklaring på kvar SSL-VPN stopp.

Trinn 1: les loggen før stolpen

Før du endrar noko, fang linjene rett før stoppet. Du leitar etter om tunneladapteren vart oppretta, om ei adresse vart tildelt, og om klienten gav opp å vente på ein adressefamilie. Eit stopp på ein annan prosent er eit anna trinn med si eiga diagnose, og ei sertifikatåtvaring eller ei feil gatewayadresse gir si eiga melding i staden for ei stille venting. Skriv ned tidsstempelet, fordi neste forsøk legg til nok ein blokk i same fila.

Viss loggen viser ei fullført innlogging etterfølgd av ingenting, er du i lokal oppsett og adapteren er ein legitim mistenkt.

Trinn 2: avgrens IPv6-endringa til éin adapter

Endringa høyrer til adapteren, ikkje maskinen. I Windows-adaptereigenskapane betyr det å fjerne Internet Protocol Version 6 (TCP/IPv6) på det aktuelle grensesnittet, og frå eit skal er det Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Stadfest tilstanden med Get-NetAdapterBinding -ComponentID ms_tcpip6 før du koplar til igjen. Kopla så til igjen og sjå om stolpen passerer 98 % i staden for å stoppe der.

Avgrens først, test så. Å slå av IPv6 globalt er ei større endring enn spørsmålet krev, og det påverkar tenester du ikkje hadde tenkt å røre.

Trinn 3: stadfest kva stoppet skjulte

Ein tunnel som koplar til, er ikkje ein tunnel som verkar. Kontroller adressa klienten tildelte, rutene profilen installerte, og namneoppslag for éin intern vert: Resolve-DnsName files.corp.example. Ein klient som koplar til og ikkje løyser opp noko, har eit DNS-problem, og det er lett å feiltolke som at den same feilen kjem tilbake.

Test éin intern ressurs ved namn og éin offentleg destinasjon, så ein øydelagd delt tunnel ikkje blir forveksla med ein reparert klient.

Trinn 4: gjer rettinga repeterbar

Viss innstillinga må ut til ein heil flåte, legg ho i distribusjonspakken eller i adapterkonfigurasjonen i staden for i eit manuelt trinn som blir gjenteke på kvar berbar. Noter i saka at stoppet på 98 % var knytt til IPv6 på nettverksgrensesnittet, og noter kva anna på verten som var avhengig av IPv6 før nokon slår det på igjen for å rette noko urelatert.

Ei retting som berre finst i hukommelsen til éin ingeniør, er ei retting som kjem tilbake neste kvartal.

Viss stolpen framleis stoppar på 98 % med IPv6 av, forklarer leverandørnotatet det ikkje lenger, og loggen er ditt neste bevis. Slutt å behandle symptomet og gå tilbake til trinn teljaren.