FortiClient-ը կախվում է 98%-ի վրա. անջատեք IPv6-ը այդ ադապտերի վրա

Ձողը հասնում է 98%-ի, հաճախորդը մնում է այնտեղ, և գաղտնաբառը նորից մուտքագրելը ոչինչ չի փոխում: Սա է օգտակար հուշումը. հաճախորդն արդեն ընդունել է դարպասի սերտիֆիկատը, ուղարկել է հավատարմագրերը և ստացել թունելի կարգավորում: Մնում է բարձրացնել վիրտուալ ադապտերը և հաստատել, որ թունելը տեղափոխում է թրաֆիկ. Երբ այդ վերջին քայլը երբեք չի ավարտվում, խափանումը տեղական է, և հավատարմագրերի որևէ նոր մուտքագրում չի հասնում դրան:

Չորս քայլ, և առաջինը ձողը չէ, այլ մատյանի ընթերցումը:

Ինչ է իրականում հաղորդում 98% հաշվիչը

Տոկոսը հաճախորդի սեփական փուլային հաշվիչն է, ոչ թե թողունակության չափ: Յուրաքանչյուր փորձի ժամանակ նույն թվի վրա կախվելը նշանակում է, որ հաճախորդը հասնում է որոշակի քայլի և սպասում. դրա համար դանդաղ կապը և կախված հաճախորդը մատյանում տարբեր տեսք ունեն: Հավատարմագրերի խնդիրը կտպեր հավատարմագրի սխալ՝ լուռ դադարի փոխարեն:

Fortinet-ը փաստագրել է այս ախտանիշը հաճախորդի կողմի մեկ պատճառի դեմ. IPv6-ը միացված է այն ադապտերի վրա, որն օգտագործում է հաճախորդը: Դա ադապտերի կարգավորումը դարձնում է առաջին փորձարկվող բանը, ոչ թե յուրաքանչյուր SSL-VPN կախման համընդհանուր բացատրություն:

Քայլ 1. կարդացեք մատյանը ձողից առաջ

Նախքան որևէ բան փոխելը, գրանցեք կախումից անմիջապես առաջ եղած տողերը: Դուք փնտրում եք՝ ստեղծվե՞լ է թունելի ադապտերը, հատկացվե՞լ է հասցե, և արդյոք հաճախորդը հրաժարվել է հասցեների ընտանիքի սպասումից: Այլ տոկոսի վրա կախվելը այլ փուլ է՝ իր ախտորոշմամբ, և սերտիֆիկատի նախազգուշացումը կամ սխալ դարպասի հասցեն ստեղծում է իր հաղորդագրությունը՝ լուռ սպասման փոխարեն: Գրանցեք ժամանականիշը, որովհետև հաջորդ փորձը նույն ֆայլին ավելացնում է ևս մեկ բլոկ:

Եթե մատյանը ցույց է տալիս ավարտված մուտք, որին հաջորդում է ոչինչ, դուք տեղական կարգավորման մեջ եք, և ադապտերը օրինական կասկածյալ է:

Քայլ 2. սահմանափակեք IPv6-ի փոփոխությունը մեկ ադապտերով

Փոփոխությունը ադապտերինն է, ոչ թե մեքենային: Windows-ի ադապտերի հատկություններում դա նշանակում է հանել Internet Protocol Version 6 (TCP/IPv6)-ը կոնկրետ ինտերֆեյսից, իսկ shell-ից այն հետևյալն է՝ Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Ստուգեք վիճակը հետևյալով՝ Get-NetAdapterBinding -ComponentID ms_tcpip6 նախքան նորից միանալը: Այնուհետև նորից միացեք և տեսեք՝ ձողը անցնում է 98%-ը, թե կանգ է առնում դրա վրա:

Նախ սահմանափակեք շրջանակը, հետո փորձարկեք: IPv6-ի գլոբալ անջատումը ավելի մեծ փոփոխություն է, քան պահանջում է հարցը, և ազդում է ծառայությունների վրա, որոնց չէիք պատրաստվում դիպչել:

Քայլ 3. ստուգեք, թե ինչ էր թաքցնում կախումը

Միացող թունելը դեռ աշխատող թունել չէ: Ստուգեք հաճախորդի հատկացրած հասցեն, պրոֆիլի տեղադրած երթուղիները և անունների լուծումը մեկ ներքին հոսթի համար՝ Resolve-DnsName files.corp.example. Հաճախորդը, որը միանում է և ոչինչ չի լուծում, DNS խնդիր ունի, և դա հեշտ է սխալ կարդալ որպես նույն խափանման վերադարձ:

Փորձարկեք մեկ ներքին ռեսուրս անունով և մեկ հանրային նպատակակետ, որպեսզի կոտրված բաժանված թունելը չշփոթեն վերանորոգված հաճախորդի հետ:

Քայլ 4. դարձրեք ուղղումը կրկնելի

Եթե կարգավորումը պետք է հասնի ամբողջ պարկին, դրեք այն տեղակայման փաթեթում կամ ադապտերի կոնֆիգուրացիայում, ոչ թե յուրաքանչյուր նոթբուքի վրա կրկնվող ձեռքով քայլում: Տոմսում գրանցեք, որ 98%-ի կախումը կապված էր ցանցային ինտերֆեյսի IPv6-ի հետ, և նշեք, թե հոսթի վրա ուրիշ ինչ էր կախված IPv6-ից, նախքան ինչ-որ մեկը նորից միացնելը՝ անկապ բան շտկելու համար:

Ուղղումը, որը գոյություն ունի միայն մեկ ինժեների հիշողության մեջ, ուղղում է, որը վերադառնում է հաջորդ եռամսյակում:

Եթե ձողը դեռ կանգ է առնում 98%-ի վրա՝ IPv6-ն անջատված, մատակարարի նշումն այլևս դա չի բացատրում, և մատյանը ձեր հաջորդ ապացույցն է: Դադարեք բուժել ախտանիշը և վերադարձեք փուլային հաշվիչին: