Azure VPN-ի NAT-ը չի լուծում համընկնող VNet հասցեները
Նույն մասնավոր միջակայքով երկու VNet չեն միանա միայն այն պատճառով, որ NAT կա։ Նախ ստուգեք միացման տեսակը, ապա վերահամարակալեք կամ տիրացեք թարգմանության կեղծանվան։
Երկու VNet-ներն էլ օգտագործում են 10.40.1.0/24, թունելները բարձրանում են, և ոչինչ չի աշխատում։ Երկրորդ VPN դարպասի ավելացումը դա չի փոխում, ոչ էլ ավելի ցածր երթուղու չափիչը, քանի որ խնդիրը ուղու ընտրության մեջ չէ։ Երկու աշխատանքային բեռներ, որոնք պատասխանում են նույն մասնավոր հասցեին, յուրաքանչյուր փաթեթ թողնում են անորոշ նպատակակետով և չստուգվող վերադարձի ուղով։ Նախքան ցանկացած թարգմանություն պլանավորելը պարզեք, թե իրականում ինչ միացման տեսակ եք ստեղծել, քանի որ այդ մեկ ընտրությունը որոշում է՝ Azure-ի NAT գործառույթը ընդհանրապես հասանելի է, թե ոչ։
Ինչ է իրականում ասում ձեզ այս ախտանիշը
Երբ VNet A-ի հոսթը ուղարկում է 10.40.1.10 հասցեին, երթուղային աղյուսակը կարող է այն միայն ինչ-որ տեղ ուղղել։ Եթե VNet B-ն նույնպես պարունակում է 10.40.1.10, այդ հասցեն այնպիսի նպատակակետ չէ, որը ուղին կարող է տարբերել. դա մեկ հասցե է երկու սեփականատիրոջով։
Երկրորդ դարպասը, որը սովորաբար տեղակայում են, չի օգնում։ Այն տալիս է ևս մեկ թունել, ոչ թե ևս մեկ հասցե, և կրկնվող միջակայքը թունելի ներսում անփոփոխ ճամփորդում է։ Այն նաև կրկնապատկում է այն կարգավորումը, որը պետք է հետևողական պահեք։ Ինչ այն չի կարող անել, դա մեկ հասցեն երկու հոսթ նշանակելն է։
VPN գործընկերների հանրային հասցեները փոխելը նույնպես ոչինչ չի տալիս։ Այդ հասցեները նշում են թունելի ծայրակետերը, մինչդեռ բախումը ներսում տեղափոխվող մասնավոր միջակայքում է։
Միացման տեսակը որոշում է՝ NAT-ը հասանելի է, թե ոչ
Azure VPN Gateway-ն իսկապես ունի NAT հնարավորություն, և այն փաստաթղթավորված է երթուղու վրա հիմնված IPsec միջկայքային միացումների համար որոշակի դարպասի SKU-ներում։ Նույն փաստաթղթերը բացառում են VNet-to-VNet և point-to-site միացումները, ուստի գործառույթը այն վանդակը չէ, որը հայտնվում է յուրաքանչյուր դարպասային հարաբերության մեջ։
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Բնիկ VNet-to-VNet-ը նաև պահանջում է, որ VNet-ի և տեղական ցանցի միջակայքերը սկզբից չհամընկնեն, ինչը համահունչ է բացառմանը։ VNet-ների զուգակցումը նույն պատճառով համընկման լուծում չէ։
Կա աջակցվող այլընտրանք, որը մարդիկ շփոթում են բնիկ տեսակի հետ. մոդելավորեք մյուս VNet-ը որպես տեղական ցանց և միացրեք այն որպես կայք-կայք միացում։ Դա այլ ռեսուրս է և այլ նախագծում, ուստի վերանվանված միացումը դիտարկեք որպես վավերացման ենթակա փոփոխություն, ոչ թե պարզ վերանվանում։
Վերահամարակալեք կամ թարգմանեք մի բանով, որը տիրապետում է կեղծանվանը
Եթե երկու VNet-ներն էլ ձերն են, համեմատեք պլանավորված վերահամարակալումը թարգմանության շարունակական արժեքի հետ։ Վերահամարակալումը շոշափում է հավելվածների կարգավորումը, DNS գրառումները, անվտանգության կանոնները և յուրաքանչյուր գոյություն ունեցող միացում, բայց հետո թողնում է սովորական ընթեռնելի ցանց։ Արեք այն մեկ ենթացանցով, DNS փոփոխությունը վերջինը։ Կիսով չափ վերահամարակալված միջակայքը ավելի վատ է, քան երկու տարբերակներից որևէ մեկը, քանի որ այդ ժամանակ երկու նախածանցներն էլ հեղինակավոր են թվում աղյուսակը հաջորդ անգամ կարդացողին։
Այնտեղ, որտեղ վերահամարակալումը գործնական չէ, օգտագործեք թարգմանված նախագծում կեղծանվան իրական սեփականատիրոջով։ VNet A-ի զանգահարողները կարող են հասնել VNet B-ի 10.40.1.10 հասցեին որպես 10.140.1.10, բայց այդ կեղծանունը պահանջում է թարգմանող սարք, դեպի այն տանող ուղի և պատասխանի համար համապատասխան վարք։ Միայն DNS-ում ավելացված հասցեն թարգմանություն չէ։
Գրանցեք երկու միջակայքերն էլ երկու ուղղություններով. ինչ է հավաքում զանգահարողը, ինչ է տեսնում նպատակակետը որպես աղբյուր, և որ կողմը կարող է նախաձեռնել։ Azure-ի սեփական NAT կանոնները ներառում են հակադարձ թարգմանությունը իրենց SNAT քարտեզագրման համար, ուստի դուք ձեռքով համապատասխան DNAT կանոն չեք գրում, բայց այդ հարմարավետությունը դադարում է այն միացման տեսակների մոտ, որոնք աջակցում է գործառույթը։
Ինչ չի աշխատի
Օգտատիրոջ կողմից սահմանված ուղին կամ երթուղու չափիչը չեն կարող ստեղծել բացակայող հասցեային տարբերակում։ Երկուսն էլ գործում են դեռ անորոշ նպատակակետի վրա, և փաթեթը հասնում է այն հաջորդ ցատկին, որը նախընտրում է աղյուսակը։
Կրկնվող միջակայքը որպես ավելի կոնկրետ նախածանց երթուղային աղյուսակին ավելացնելը անորոշությունը տեղափոխում է ընդամենը մեկ քայլ։ Այն նաև հակված է կոտրելու մյուս ուղղությունը, որտեղ պատասխանն այժմ ունի երկու հավանական աղբյուր։
Ընդունեք նախագծումը երկու ուղղությունների երթևեկությամբ
Ապացուցեք նախագծումը յուրաքանչյուր կողմից թարմ թույլատրված գործողությամբ, ոչ թե թունելի կարգավիճակով։ Միացված IPsec թունելը ասում է, որ գործընկերները համաձայն են գաղտնագրման շուրջ. այն ոչինչ չի ասում այն մասին, թե արդյոք նպատակակետերը դարձան տարբերելի։
Այնուհետև գործարկեք մերժված ուղիները. հասցե, որը պետք է մնա անհասանելի, և ծառայություն, որը քաղաքականությունը պետք է արգելափակի։ Եթե երկուսն էլ դեռ հաջողվում են, թարգմանությունն ավելի լայն է, քան նախատեսել էր նախագծումը։
Ավարտեք այն փաստերով, որոնք հետագայում կբացատրեն կարգավորումը. սկզբնական միջակայքը, ներկայացված միջակայքը, թարգմանող սարքը և այն ուղղությունը, որով յուրաքանչյուր կողմ կարող է նախաձեռնել։ Եթե դրանցից որևէ մեկը բացակայում է, հաջորդ ինժեները ժառանգում է ցանց, որտեղ երկու հոսթ կիսում են մեկ անուն, և ոչ ոք չի հիշում, թե ինչու է նրանցից մեկը պատասխանում։