Ձեռքսեղմումը կա, ինտերնետը՝ ոչ. ինչ ուղղել առաջինը Windows 11-ում

Windows 11-ում հաճախ թարմ ձեռքսեղմումները կանգնում են դիտարկիչների կողքին, որոնք ոչինչ չեն բացում։ Ձեռքսեղմումը միայն ապացուցում է, որ գործընկերոջ հետ UDP փոխանակումն ավարտվել է։ Այն ոչինչ չի ասում Windows-ի սահմանած երթուղու, օգտագործվող լուծիչի, ոչ էլ այն մասին, թե արդյոք ելքը ընդհանրապես ինչ-որ բան է փոխանցում։

Չորս պայման են որոշում, թե այդ շերտերից որն է ձախողվել։ Դրանք հերթով անցնելը տևում է րոպեներ, մինչդեռ բանալիները վերագրելը ավելի երկար է տևում և ոչինչ չի փոխում։

Որոշեք շերտը, նախքան բանալիներին դիպչելը

Անցեք երեք նպատակակետերով, այս հերթականությամբ։ Սկսեք թունելի կողմի հասցեով, ապա հանրային IP՝ թվի տեսքով, և ավարտեք հոսթի անունով։ Որտեղ հաջորդականությունը կտրվում է, այնտեղ էլ նշվում է շերտը։ Առաջին քայլի ձախողումը երթուղավորումն է, երկրորդինը՝ փոխանցումը կամ NAT-ը, իսկ երրորդինը՝ անունների լուծումը։

Այդ հերթականությունը ողջ մեթոդն է։ Այն խանգարում է DNS խափանումը ախտորոշել որպես կոտրված թունել, ինչը այստեղ ամենատարածված սխալ շրջադարձն է։

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Եթե ձեռքսեղմման ժամանակը դատարկ է

Երբ ձեռքսեղմման ժամանակը դատարկ է, գաղտնագրված փոխանակումը երբեք չի ավարտվել։ Ուստի խափանումը գտնվում է երթուղավորումից առաջ։ Նախ նայեք ծայրակետի հասցեին և պորտին, ապա՝ թե ցանցը զտում է UDP-ն։ Հոսթինգի մատակարարը, որը գցում է WireGuard-ի թրաֆիկը, հենց սա է առաջացնում, և նաև այն հաճախորդը, որը ծայրակետը պատճենել է հին պրոֆիլից։

Ելք գնացող բայթերը՝ առանց որևէ ներս եկողի, այլ դեպք է։ Դա մատնանշում է NAT-ի կամ հրապարի, որը թրաֆիկը վերադարձնում է սխալ տեղ։

Եթե երթուղին պարտվում է ֆիզիկական ադապտերին

Ամբողջական թունելի համար գործընկերոջ բաժինը պետք է ծածկի այն նպատակակետերը, որոնք ակնկալում եք օգտագործել։ Windows-ը երբեմն պահում է ֆիզիկական ադապտերի լռելյայն երթուղին՝ անգամ ամեն ինչ ընդգրկող կանոն սահմանված լինելու դեպքում։ Ամեն ինչ ընդգրկող կանոնը 0.0.0.0/1 և 128.0.0.0/1-ի բաժանելը ստեղծում է երկու ավելի կոնկրետ նախածանց, որոնք հաղթում են որոնմանը։ Բաժանումը փաստաթղթավորված շրջանցում է, ոչ թե նախընտրություն։

Հաստատեք route print-ով կամ հանրային հասցեի որոնմամբ։ Ընտրված ինտերֆեյսը պետք է լինի թունելի ադապտերը։ Եթե ֆիզիկականը դեռ հաղթում է, ուղղեք գործընկերոջ միջակայքերը՝ նախքան սերվերին դիպչելը։

Եթե հասցեները աշխատում են, իսկ անունները՝ ոչ

WireGuard-ը կրում է IP փաթեթներ և կարծիք չունի DNS-ի մասին։ Դրեք DNS = տողը ինտերֆեյսի բաժնում, կամ կարգավորեք ադապտերը Windows-ի միջոցով։ Առանց դրա՝ հասցեով ping-ը հաջողվում է, մինչդեռ ամեն հոսթի անուն ձախողվում է, և օգտատերերը դա հաղորդում են որպես ինտերնետի բացակայություն։

Ստուգեք, թե Windows-ը միանալուց հետո իրականում որ սերվերներն է օգտագործում։ Ֆիզիկական ադապտերի վրա մնացած լուծիչը բացատրում է մասնակի ձախողումը, երբ որոշ անուններ լուծվում են, իսկ որոշները՝ ոչ։ Մաքրեք այն՝ վրան երկրորդն ավելացնելու փոխարեն։

Եթե Windows մեքենան ելքն է

Internet Connection Sharing-ը միացված լինելիս վերագրում է հասցեավորումը, ինչը կարող է ընդհանուր ադապտերը տեղափոխել այլ միջակայք։ Սկզբնական հասցեին դեռ ուղղված հաճախորդը դադարում է աշխատել։ ScopeAddress և StandaloneDHCPAddress ռեեստրի արժեքները կառավարում են այդ միջակայքը, և կարգավորումը կարող է վերադառնալ վերագործարկումից հետո։

Windows-ին հատուկ ևս երկու բախում արժե նայել։ Routing and Remote Access ծառայությունը կարող է խանգարել թունելին։ Սխալ ճարտարապետության համար կառուցված տեղադրիչը ձախողվում է հաղորդագրությամբ, որը երբեք չի հիշատակում ճարտարապետությունը։

Ուղղեք այն շերտը, որը նշել է թեստը, ապա նորից գործարկեք նույն երեք նպատակակետերը։ Այն փոփոխությունը, որը վերականգնում է հոսթի անվան թեստը, բայց կոտրում է թունելի հասցեն, կիրառվել է սխալ շերտի վրա։