Azure կայքից կայք VPN՝ NAT-ի հետևում գտնվող զուգընկերով. ստուգաթերթ

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

Քայլ 1. հաստատեք, որ զուգընկերը ընդհանրապես NAT-ի հետևում է

Համեմատեք սարքի WAN միջերեսի հասցեն այն հասցեի հետ, որը Azure-ը տեսնում է դրա համար։ Եթե դրանք տարբերվում են, ինչ-որ բան թարգմանում է, և այդ թարգմանիչն այժմ ձեր VPN նախագծի մասն է։ Հարցրեք մատակարարին՝ քարտեզագրումը ստատիկ է, թե ընդհանուր, քանի որ ընդհանուր քարտեզագրումը փոխում է այն, ինչի վրա կարող եք հույս դնել։ Մասնավոր WAN հասցեով և առանց փոխանցման սարքը այլ դեպք է, քան օպերատորի մակարդակի NAT-ի հետևում գտնվող սարքը՝ կայուն հանրային քարտեզագրմամբ։

Եթե երկու հասցեները համընկնում են, կանգ առեք այստեղ. NAT-ը ձեր խնդիրը չէ, և այս ցանկի մնացած մասը չի օգնի։

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

Քայլ 2. պայմանավորվեք, թե ով է սկսում

Azure VPN Gateway-ի հաճախ տրվող հարցերը նշում են NAT-T աջակցությունը և ավելացնում, որ տեղական սարքը պետք է սկսի IPsec թունելը, երբ գտնվում է NAT-ի հետևում։ Դա համապատասխանում է վիճակով թարգմանության աշխատանքին, քանի որ թարգմանիչը քարտեզագրում է պահում, որովհետև ներքին սարքն ուղարկել է առաջին փաթեթը։ Եթե սպասվում է, որ Azure-ը կսկսի, և ոչինչ չի գալիս այդ քարտեզագրումը ստեղծելու համար, թունելը երբեք չի սկսվում։

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

Դիտեք IKE փոխանակումը սարքում ձեռքով մեկնարկի ժամանակ. այնտեղ լռությունը երթուղավորման կամ հրային պատի պատասխան է, ոչ Azure-ի պատասխան։

Քայլ 3. ճիշտ սահմանեք զուգընկերի հասցեն

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

Եթե հանրային հասցեն փոխվում է, այդ օբյեկտը պետք է փոխվի դրա հետ։ Հնացած հասցեի վերածվող անունն ավելի վատ է, քան ստատիկ հասցեն, որը պետք է ձեռքով թարմացնեք։

Գրեք բոլոր երեք արժեքները՝ սարքի տեղական հասցեն, թարգմանված հանրային հասցեն, կարգավորված զուգընկերի ինքնությունը։

Քայլ 4. բացեք միայն այն պորտերը, որոնք NAT-T-ին պետք են

NAT-T-ն ESP-ն տեղափոխում է UDP-ի ներսում, և RFC 3948-ը նկարագրում է այդ փաթաթումը 4500 պորտով, որն օգտագործվում է 500 պորտի սկզբնական բանակցությունից հետո։ Ձեր հրային պատը և թարգմանիչը երկուսն էլ պետք է թույլ տան փոխանակումը և դրա վերադարձի տրաֆիկը։ Չկապված TCP պորտ թույլ տալը ոչինչ չի ապացուցում այս ուղու մասին, և կանոնը, որը թույլ է տալիս ելքը, բայց ոչ պատասխանը, դեռ կձախողվի։

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

Մեկ անգամ վերցրեք թարգմանչի երկու կողմերում. փաթաթման տարբերությունը անմիջապես երևում է։

Քայլ 5. առանձնացրեք արտաքին տրանսպորտը ներքին երթուղավորումից

Թունելը, որը հաստատվում է և ոչինչ չի տեղափոխում, երթուղավորման խնդիր է, ոչ NAT-T-ի խնդիր։ Կայքերին դեռ պետք են համատեղելի տրաֆիկի ընտրիչներ, համապատասխան հասցեային տարածություններ, մուտքի կանոններ և վերադարձի ուղի հավելվածների ցանցերի համար։ Այդ ամենից ոչինչ չի տալիս հաջող IKE փոխանակումը։

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

Նախքան ինչ-որ բան փոխելը դասակարգեք ձախողումը ըստ փուլի, և պահեք այդ դասակարգումը տոմսում, որպեսզի հաջորդ մարդը սկսի այնտեղ, որտեղ դուք կանգ առաք։