Windows-ի NAT-T գրանցամատյանի արժեքը. նախ ստուգեք տոպոլոգիան

Windows VPN միացումը ձախողվում է, որոնումը վերադարձնում է գրանցամատյանի արժեք, և արժեքը մուտքագրվում է վերագործարկման հետ միասին։ Այդ հաջորդականությունը երբեմն աշխատում է և երբեք ոչինչ չի բացատրում։ Քննարկվող կարգավորումը պատասխանում է մեկ հարցի՝ որտեղ է սերվերը NAT սարքի նկատմամբ, և այն անիմաստ է, քանի դեռ չգիտեք, թե որ արձանագրությունը և որ փուլում ձախողվեց։

Ինչ է իրականում ընտրում արժեքը

AssumeUDPEncapsulationContextOnSendRule-ը որոշում է՝ արդյոք Windows-ի IPsec իրականացումը կփորձի ասոցիացիաներ ստեղծել NAT սարքի հետևում գտնվող գործընկերոջ հետ։ Փաստաթղթավորված լռելյայն 0-ը չի թույլատրում այդ դեպքը, 1-ը թույլատրում է, երբ սերվերը NAT-ի հետևի կողմն է, իսկ 2-ը ընդգրկում է երկու ծայրերի թարգմանությունը։ Սրանք տոպոլոգիայի մասին պնդումներ են՝ ով որտեղ է։

Հաջորդականություն կարդալով՝ թվերը նկարագրում են ավելի ու ավելի թարգմանություն, ոչ թե ավելի ու ավելի հուսալիություն։ 2-ի սահմանումը ցանցում, որտեղ ոչինչ չի թարգմանվում, միացումը չի դարձնում ավելի արագ կամ կայուն և չի վերանորոգում նույնականացման ձախողումը։ Microsoft-ի NAT ուղեցույցը L2TP/IPsec-ի համար փաստաթղթավորում է քաղաքականությունը և դրա պատմական հարթակային համատեքստը։ Համեմատեք այդ համատեքստը ձեր իրականում օգտագործվող Windows տարբերակի և դերի հետ, որովհետև մի քանի թողարկում վերապրած փաստաթուղթը պնդում չէ յուրաքանչյուր ընթացիկ կառուցվածքի մասին։

Համապատասխանեցրեք տոպոլոգիան թվից առաջ

Նկարեք ուղին և նշեք թարգմանության կետերը՝ արդյոք հաճախորդը տնային երթուղիչի հետևում է, արդյոք սերվերը բեռնվածքի հավասարակշռիչի կամ հասցեները վերաշարադրող հրդեպատի հետևում է, և արդյոք ծայրերից մեկը ձեր չվերահսկվող օպերատորի թարգմանության հետևում է։ Միայն այդ նկարից հետո կարող եք որոշել՝ արժեքը կիրառելի է, և որ ծայրի համար։

Այն պնդումը, թե ընթացիկ Windows Server տարբերակները պարզապես գալիս են անջատված NAT traversal-ով, չափազանց լայն է գործելու համար։ Կարևոր է ձեր համակարգի քաղաքականությունը, դրա դիմացի տոպոլոգիան և ձախողված փոխանակումը՝ այդ հերթականությամբ։ Եթե երկու ծայրերն էլ հանրային հասցեներ ունեն, կարգավորումը ձեր խնդիրը չէ։ Փոխարենը նայեք առաջարկին, վկայագրին կամ հաշվին, և թողեք գրանցամատյանը հանգիստ։

Նախ ստուգեք ձախողման փուլը

L2TP/IPsec առաջացնում է առնվազն երեք տարբեր ձախողում՝ գործընկերոջը հնարավոր չէ հասնել, IPsec պաշտպանությունը հնարավոր չէ հաստատել, և PPP օգտվողի նույնականացումը մերժվում է թունելի գոյությունից հետո։ Մերժված հաշիվը չի վերանորոգվում NAT քաղաքականությունը փոխելով, և առաջարկների անհամապատասխանությունը չի վերանորոգվում վերագործարկմամբ։

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Առանց պատասխանողի ժամանակի սպառումը հուշում է հասանելիության կամ զտման, ոչ թե քաղաքականության մասին։ Արագ մերժումը՝ առաջարկի հաղորդագրությամբ, մատնանշում է ալգորիթմներին։ Թունելի բարձրացումից հետո ձախողումը պատկանում է նույնականացման փուլին, որը այլ սեփականատեր և այլ լուծում է։

HTTPS-ի վրա SSTP-ն և բնիկ IKEv2-ը ունեն իրենց մատյաններն ու իրենց կառավարումը։ Դրանցից ոչ մեկը չի դառնում NAT-traversal դեպք միայն այն պատճառով, որ դրանք նույնպես աշխատում են Windows-ում։

Կատարեք փոփոխությունը վերադարձի ուղով

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

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