FortiClient ngec në 98%: çaktivizo IPv6 në atë përshtatës

Shiriti arrin 98%, klienti rri atje, dhe ritipizimi i fjalëkalimit nuk ndryshon asgjë. Ky është gjurma e dobishme: klienti ka pranuar tashmë certifikatën e portës, ka dërguar kredencialet dhe ka marrë një konfigurim tuneli. Ajo që mbetet është të ngrihet përshtatësi virtual dhe të konfirmohet se tuneli transporton trafik. Kur ai hap i fundit nuk përfundon kurrë, defekti është lokal, dhe asnjë sasi ritipizimi i kredencialeve nuk e arrin atë.

Katër hapa, dhe i pari është leximi i regjistrit, jo i shiritit.

Çfarë raporton në të vërtetë numëruesi i 98%

Përqindja është numëruesi i fazave të vetë klientit, jo një masë e qarkullimit. Ngecja në të njëjtin numër në çdo përpjekje do të thotë se klienti arrin një fazë të caktuar dhe pret; kjo është arsyeja pse një lidhje e ngadaltë dhe një klient i ngecur duken ndryshe në regjistër. Një problem me kredencialet do të printonte një gabim kredencialesh në vend të një pauze të heshtur.

Fortinet e dokumentoi këtë simptom kundrejt një shkaku nga ana e klientit: IPv6 i aktivizuar në përshtatësin që përdor klienti. Kjo e bën konfigurimin e përshtatësit gjënë e parë për të testuar, jo një shpjegim universal për çdo SSL-VPN ngecje.

Hapi 1: lexo regjistrin para shiritit

Para se të ndryshoni ndonjë gjë, kapni rreshtat menjëherë para ngecjes. Po kërkoni nëse përshtatësi i tunelit u krijua, nëse u caktua një adresë dhe nëse klienti hoqi dorë nga pritja për një familje adresash. Një ngecje në një përqindje tjetër është një fazë tjetër me diagnozën e vet, dhe një paralajmërim certifikate ose një adresë e gabuar porte prodhon mesazhin e vet në vend të një pritjeje të heshtur. Shënoni vulën kohore, sepse përpjekja tjetër shton një bllok tjetër në të njëjtin skedar.

Nëse regjistri tregon një hyrje të përfunduar të ndjekur nga asgjë, ju jeni në konfigurimin lokal dhe përshtatësi është një i dyshuar legjitim.

Hapi 2: kufizo ndryshimin e IPv6 në një përshtatës

Ndryshimi i përket përshtatësit, jo makinës. Në vetitë e përshtatësit të Windows kjo do të thotë të hiqet Internet Protocol Version 6 (TCP/IPv6) në ndërfaqen specifike, dhe nga një shell është Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Konfirmo gjendjen me Get-NetAdapterBinding -ComponentID ms_tcpip6 përpara se të rilidheni. Pastaj rilidhuni dhe shikoni nëse shiriti kalon 98% në vend që të ndalet atje.

Së pari kufizo fushën, pastaj testo. Çaktivizimi i IPv6 globalisht është një ndryshim më i madh sesa kërkon pyetja dhe prek shërbime që nuk kishit ndërmend t'i prekni.

Hapi 3: verifiko çfarë fshehu ngecja

Një tunel që lidhet nuk është një tunel që funksionon. Kontrollo adresën që caktoi klienti, rrugët që instaloi profili dhe zgjidhjen e emrave për një host të brendshëm: Resolve-DnsName files.corp.example. Një klient që lidhet dhe nuk zgjidh asgjë ka një problem DNS, dhe kjo lexohet lehtë gabimisht si kthimi i të njëjtit defekt.

Testo një burim të brendshëm sipas emrit dhe një destinacion publik, që një tunel i ndarë i prishur të mos ngatërrohet me një klient të rregulluar.

Hapi 4: bëje rregullimin të përsëritshëm

Nëse konfigurimi duhet të arrijë një flotë, vendose në paketën e shpërndarjes ose në konfigurimin e përshtatësit në vend të një hapi manual të përsëritur në çdo laptop. Shënoni në tiketë se ngecja në 98% ishte e lidhur me IPv6 në ndërfaqen e rrjetit, dhe vini re çfarë tjetër në host varej nga IPv6 përpara se dikush ta riaktivizojë për të rregulluar diçka të palidhur.

Një rregullim që ekziston vetëm në kujtesën e një inxhinieri është një rregullim që kthehet tremujorin tjetër.

Nëse shiriti ende ndalon në 98% me IPv6 të çaktivizuar, shënimi i furnizuesit nuk e shpjegon më dhe regjistri është prova juaj e radhës. Ndaloni trajtimin e simptomës dhe kthehuni te numëruesi i fazave.