FortiClient jumittuu 98 %:ssa: poista IPv6 käytöstä kyseisestä sovittimesta

Palkki saavuttaa 98 %, asiakas jää siihen, eikä salasanan kirjoittaminen uudelleen muuta mitään. Tässä on hyödyllinen vihje: asiakas on jo hyväksynyt yhdyskäytävän varmenteen, lähettänyt tunnistetiedot ja vastaanottanut tunnelin määrityksen. Jäljelle jää nostaa virtuaalisovitin ja varmistaa, että tunneli kuljettaa liikennettä. Kun tuo viimeinen vaihe ei koskaan valmistu, vika on paikallinen, eikä mikään määrä tunnistetietojen uudelleenkirjoitusta yllä siihen.

Neljä vaihetta, ja ensimmäinen on lokin lukeminen palkin sijaan.

Mitä 98 %:n laskuri oikeastaan ilmoittaa

Prosentti on asiakkaan oma vaihelaskuri, ei läpäisyn mitta. Jumittuminen samaan lukuun joka yrityksellä tarkoittaa, että asiakas saavuttaa tietyn vaiheen ja odottaa; siksi hidas yhteys ja jumittunut asiakas näyttävät lokissa erilaisilta. Tunnistetietojen ongelma tulostaisi tunnistetietovirheen hiljaisen tauon sijaan.

Fortinet dokumentoi tämän oireen yhtä asiakaspuolen syytä vastaan: IPv6 on käytössä sovittimessa, jota asiakas käyttää. Siksi sovittimen asetus on ensimmäinen kokeiltava asia, ei yleinen selitys jokaiselle SSL-VPN jumille.

Vaihe 1: lue loki ennen palkkia

Ennen kuin muutat mitään, tallenna rivit välittömästi ennen jumia. Etsit, luotiinko tunnelisovitin, annettiinko osoite ja lakkasiko asiakas odottamasta osoiteperhettä. Jumi eri prosentissa on eri vaihe omine diagnooseineen, ja varoitus varmenteesta tai väärä yhdyskäytävän osoite tuottaa oman viestinsä hiljaisen odotuksen sijaan. Kirjoita aikaleima muistiin, koska seuraava yritys lisää samaan tiedostoon uuden lohkon.

Jos loki näyttää valmistuneen kirjautumisen ja sen jälkeen ei mitään, olet paikallisessa määrityksessä ja sovitin on uskottava epäilty.

Vaihe 2: rajaa IPv6-muutos yhteen sovittimeen

Muutos kuuluu sovittimeen, ei koneeseen. Windowsin sovittimen ominaisuuksissa se tarkoittaa Internet Protocol Version 6 (TCP/IPv6) -valinnan poistamista kyseiseltä liitännältä, ja komentotulkilta se on Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Vahvista tila komennolla Get-NetAdapterBinding -ComponentID ms_tcpip6 ennen uudelleenyhdistämistä. Yhdistä sitten uudelleen ja katso, ohittaako palkki 98 % sen sijaan, että pysähtyy siihen.

Rajaa ensin, testaa sitten. IPv6:n poistaminen käytöstä maailmanlaajuisesti on suurempi muutos kuin kysymys vaatii, ja se vaikuttaa palveluihin, joihin et aikonut koskea.

Vaihe 3: varmista, mitä jumi peitteli

Yhdistyvä tunneli ei ole toimiva tunneli. Tarkista osoite, jonka asiakas määritti, reitit, jotka profiili asensi, ja nimien selvitys yhdelle sisäiselle isännälle: Resolve-DnsName files.corp.example. Asiakkaalla, joka yhdistää eikä selvitä mitään, on DNS-ongelma, ja se on helppo lukea väärin saman vian paluuksi.

Testaa yksi sisäinen resurssi nimeltä ja yksi julkinen kohde, jotta rikkinäinen split-tunneli ei menisi sekaisin korjatun asiakkaan kanssa.

Vaihe 4: tee korjauksesta toistettava

Jos asetuksen on saavutettava laivue, laita se käyttöönottopakettiin tai sovittimen määritykseen sen sijaan, että se olisi jokaisella kannettavalla toistettava manuaalinen vaihe. Kirjaa tikettiin, että 98 %:n jumi liittyi IPv6:een verkkoliitännässä, ja merkitse, mitä muuta isännällä oli IPv6:n varassa, ennen kuin joku ottaa sen uudelleen käyttöön korjatakseen jotain asiaankuulumatonta.

Korjaus, joka on vain yhden insinöörin muistissa, on korjaus, joka palaa seuraavalla neljänneksellä.

Jos palkki pysähtyy yhä 98 %:iin IPv6:n ollessa pois, toimittajan huomautus ei enää selitä sitä ja loki on seuraava todisteesi. Lopeta oireen hoitaminen ja palaa vaihelaskuriin.