FortiClient blokiĝas je 98%: malŝaltu IPv6 en tiu adaptilo

La stango atingas 98%, la kliento restas tie, kaj reenigi la pasvorton nenion ŝanĝas. Tio estas la utila signo: la kliento jam akceptis la atestilon de la enirejo, sendis legitimilojn kaj ricevis tunelan agordon. Kio restas estas levi la virtualan adaptilon kaj konfirmi, ke la tunelo portas trafikon. Kiam tiu lasta paŝo neniam finiĝas, la fuŝo estas loka, kaj nenia kvanto da reenigo de legitimiloj atingas ĝin.

Kvar paŝoj, kaj la unua estas legi la protokolon anstataŭ la stangon.

Kion la nombrilo 98% fakte raportas

La procento estas la propra etapa nombrilo de la kliento, ne mezuro de trapenetro. Blokiĝo ĉe la sama nombro ĉe ĉiu provo signifas, ke la kliento atingas specifan paŝon kaj atendas; tial malrapida konekto kaj blokita kliento aspektas malsame en la protokolo. Problemo pri legitimiloj presus legitimilan eraron anstataŭ silenta paŭzo.

Fortinet dokumentis ĉi tiun simptomon kontraŭ unu kaŭzo ĉe la klienta flanko: IPv6 ŝaltita en la adaptilo, kiun la kliento uzas. Tio faras la adaptilan agordon la unuan aferon por testi, ne universalan klarigon por ĉiu SSL-VPN blokiĝo.

Paŝo 1: legu la protokolon antaŭ la stango

Antaŭ ol ŝanĝi ion ajn, kaptu la liniojn tuj antaŭ la blokiĝo. Vi serĉas, ĉu la tunela adaptilo estis kreita, ĉu adreso estis atribuita, kaj ĉu la kliento ĉesis atendi adresan familion. Blokiĝo ĉe alia procento estas alia etapo kun propra diagnozo, kaj atestila averto aŭ malĝusta enireja adreso produktas sian propran mesaĝon anstataŭ silenta atendo. Notu la tempindikon, ĉar la sekva provo aldonas alian blokon al la sama dosiero.

Se la protokolo montras finitan ensaluton sekvatan de nenio, vi estas en loka agordo kaj la adaptilo estas legitima suspektito.

Paŝo 2: limigu la IPv6-ŝanĝon al unu adaptilo

La ŝanĝo apartenas al la adaptilo, ne al la maŝino. En la adaptilaj propraĵoj de Windows tio signifas malŝalti Internet Protocol Version 6 (TCP/IPv6) en la koncerna fasado, kaj el ŝelo ĝi estas Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Konfirmu la staton per Get-NetAdapterBinding -ComponentID ms_tcpip6 antaŭ rekonekto. Poste rekonektu kaj observu, ĉu la stango preterpasas 98% anstataŭ halti ĉe ĝi.

Unue limigu la amplekson, poste testu. Malŝalti IPv6 tutmonde estas pli granda ŝanĝo ol la demando postulas, kaj ĝi efikas al servoj, kiujn vi ne intencis tuŝi.

Paŝo 3: kontrolu, kion la blokiĝo kaŝis

Tunelo, kiu konektiĝas, ne estas tunelo, kiu funkcias. Kontrolu la adreson, kiun la kliento atribuis, la vojojn, kiujn la profilo instaligis, kaj la nomrezolucion por unu interna gastiganto: Resolve-DnsName files.corp.example. Kliento, kiu konektiĝas kaj rezoluciaĉas nenion, havas DNS-problemon, kaj tio facile mislegiĝas kiel reveno de la sama fuŝo.

Testu unu internan rimedon laŭ nomo kaj unu publikan celon, por ke difektita split-tunelo ne estu konfuzita kun riparita kliento.

Paŝo 4: faru la riparon ripetebla

Se la agordo devas atingi floton, metu ĝin en la disfaldan pakaĵon aŭ en la adaptilan agordon anstataŭ en manan paŝon ripetatan en ĉiu tekkomputilo. Notu en la bileto, ke la blokiĝo je 98% estis ligita al IPv6 en la reta fasado, kaj notu, kio alia en la gastiganto dependis de IPv6 antaŭ ol iu reŝaltos ĝin por ripari ion senrilatan.

Riparo, kiu ekzistas nur en la memoro de unu inĝeniero, estas riparo, kiu revenos en la venonta kvaronjaro.

Se la stango ankoraŭ haltas je 98% kun IPv6 malŝaltita, la noto de la vendisto jam ne klarigas ĝin kaj la protokolo estas via sekva pruvo. Ĉesu trakti la simptomon kaj revenu al la etapa nombrilo.