Azure-ի մասնավոր IP VPN ExpressRoute-ով՝ առանց NVA-ի

Առասպելն այն է, որ ExpressRoute-ի մասնավոր peering-ով երթևեկության գաղտնագրումը պահանջում է վիրտուալ ցանցային սարք։ Չի պահանջում։ Azure-ը աջակցում է Site-to-Site VPN Gateway-ին, որի թունելի վերջնակետը մասնավոր RFC1918 հասցե է, որը տեղափոխվում է շղթայով, և սարքը պարտադիր չէ, այն կառուցվածքային չէ։ Այն, ինչ սարքի առասպելը թաքցնում է, այն մասն է, որ իրոք ցավեցնում է՝ մասնավոր վերջնակետը մի օբյեկտի վրա միացնելը երկուսի փոխարեն, և թույլ տալը, որ ուղիղ peering երթուղին լուռ հաղթի գաղտնագրված ուղու վրա։

Որտեղից է առաջացել առասպելը

Պնդումը պատկառելի արմատներ ունի։ Տարիներ շարունակ մասնավոր peering-ով IPsec-ի գործնական բաղադրատոմսը NVA էր, քանի որ կառավարվող դարպասը բացում էր միայն հանրային վերջնակետեր։ Դա փոխվեց, և փոփոխությունից առաջ գրված պատասխանները դեռ մեջբերվում են թեմաներում, որտեղ ոչ ոք չի ստուգում ամսաթիվը։ Ուղղումը նեղ է՝ մասնավոր հասցեով VPN դարպաս գոյություն ունի, և այն փոխում է վերջնակետը, ոչ թե դրա շուրջ երթուղային տրամաբանությունը։

Այս ամենը NVA-ին թոշակի չի ուղարկում։ Այն թոշակի է ուղարկում այն ենթադրությունը, որ սարքը պահանջին հասնելու միակ ուղին է։

Միացրեք մասնավոր վերջնակետը երկու մակարդակներում

Սկսեք աշխատող ExpressRoute մասնավոր peering կապուղուց, որը կցված է VPN դարպասը պարունակող VNet-ին։ Տեղական կողմն արդեն պետք է հասնի համապատասխան մասնավոր հասցեներին այդ շղթայի միջով, քանի որ թունելը կօգտագործի այդ հասցեները որպես տրանսպորտ։ Ապա դարպասի նախապայմանը՝ Microsoft-ի մասնավոր IP VPN-ի ընթացակարգը պահանջում է Standard հանրային IP ռեսուրսի վրա կառուցված դարպաս։ Մասնավոր թունելային հասցեավորումը չի վերացնում այդ պահանջը, ինչը զարմացնում է նրանց, ովքեր կարծում են, որ «մասնավոր» նշանակում է «ոչ մի տեղ հանրային IP»։

Այժմ միացրեք դրոշակը երկու տեղում։ Դարպասի կոնֆիգուրացիան ունի իր անջատիչը մասնավոր IP-ների համար, և առանձին Site-to-Site կապուղին ունի երկրորդը, որը ստիպում է այդ կապուղուն օգտագործել մասնավոր հասցեն։ Մեկը միացնելը և մյուսը ոչ՝ ամենատարածված թերի կոնֆիգուրացիան է. թունելը կամ չի կառուցվում, կամ կառուցվում է սխալ վերջնակետին։

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

Երկրորդ առասպելը՝ կառուցված թունելը գաղտնագրում է ձեր երթևեկությունը

Երկու ուղի հիմա հասնում են հավելվածի ցանցին՝ ուղիղ մասնավոր peering ուղին և VPN-ով անցնող ուղին։ Երկուսն էլ աշխատում են։ Միայն մեկն է կիրառում այս IPsec շերտը։ Microsoft-ը փաստագրում է, որ երբ նույն նախածանցերը հայտարարվում են ExpressRoute-ով և VPN-ով, Azure-ը նախընտրում է ուղիղ ExpressRoute ուղին, ուստի առողջ թունելը առողջ հաշվիչներով ոչինչ չի ապացուցում այն մասին, թե ուր գնացին հավելվածի փաթեթները։

Փաստագրված ուղղորդման մեթոդներն են ծածկող տիրույթ ExpressRoute-ի վրա և ավելի կոնկրետ պաշտպանված տիրույթ VPN-ի վրա, կամ երկու ուղիներում անջատ նախածանցներ։ Օրինակ՝ մասնավոր peering-ը կարող է կրել 10.40.0.0/16, մինչ VPN-ը հայտարարում է 10.40.12.0/24։ Ավելի կոնկրետ նախածանցը հաղթում է, և տիրույթի մնացած մասը մնում է ուղիղ։

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

Որոշեք, թե ինչ է լինում, երբ թունելն ընկնում է

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

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

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