Azure peering, թե՞ VPN VNet-ից VNet. Որոշեք մինչև երթուղավորումը

Azure-ը ձեզ տալիս է երկու վիրտուալ ցանցեր միացնելու առնվազն երկու եղանակ, և դրանք նույն օբյեկտի փոխարինելի կարգավորումներ չեն։ Peering-ը միացնում է VNet-երը Microsoft-ի ողնաշարով առանց դարպասի. VPN VNet-ից VNet-ը IPsec հարաբերություն է դնում երկու դարպասների միջև, որոնք դուք տեղակայում, չափագրում և վերահսկում եք։ Որոշումը հանգում է երեք պայմանի, և եթե չեք կարող պատասխանել երեքին էլ մինչև երթուղի ավելացնելը, դուք պատրաստվում եք շրջանցում կառուցել մի մոդելի համար, որը երբեք չեք ընտրել։

Երեք պայման, որոնք որոշում են մոդելը

Առաջինն այն է, թե արդյոք պահանջի ինչ-որ մասի պետք է IPsec սահման, որը ձերն է և որին կարող եք մատնանշել։ Երկրորդն այն է, թե արդյոք հասցեների տարածքները մաքուր են, և երկու VNet-երը պետք է խոսեն միայն միմյանց հետ։ Երրորդն այն է, թե ով է տիրապետում ցանկացած անցողական ուղուն և դարպասի հաշվին։ Պատասխանե՛ք այդ հերթականությամբ, որովհետև առաջինը կարող է բացառել peering-ը, որքան էլ գրավիչ թվա երկրորդը։

Երկու մոդելներին ընդհանուր է հասցեավորման խիստ կանոնը. VNet-երի հասցեների տարածքները չպետք է համընկնեն։ Ոչ peering-ը, ոչ VNet-ից VNet VPN-ը աջակցվող եղանակ չեն երկու նույնական տիրույթներ միարժեք դարձնելու համար, և համընկնումը պահանջում է քարտեզագրման ձևավորում կամ վերանախագծում, ոչ թե միացման այլ տեսակ։

Պայման 1. ձեզ պե՞տք է IPsec սահման, որը ձերն է:

Peering-ը տրաֆիկը տանում է Azure-ի մասնավոր ողնաշարով և չի պահանջում VPN դարպաս հենց peered միացման համար։ Սա հայտարարություն է տրանսպորտի մասին, ոչ թե գաղտնագրման հայտարարություն, որը կարող եք աուդիտորին տալ որպես «մենք IPsec ենք աշխատեցնում»։ Եթե պահանջը նշում է հաճախորդի կարգավորած թունել, կոնկրետ IKE քաղաքականություն կամ սահման, որը վերջանում է ձեր վերահսկողության տակ գտնվող սարքավորումում, peering-ը չի բավարարում այն, որքան էլ ողնաշարը մասնավոր լինի։

VNet-ից VNet VPN-ը տալիս է այդ սահմանը. երկու դարպաս, IPsec/IKE հարաբերություն, համօգտագործված բանալիներ և դրա հետ եկող ողջ գործառնական մակերեսը։ Դուք ժառանգում եք թունելի վիճակը, դարպասի հզորությունը, SKU սահմանափակումները և վերահսկողությունը, որն ապացուցում է, որ թունելը աշխատում է։ Սա ճիշտ պատասխանն է, երբ պահանջը վերաբերում է հենց այդ սահմանին, որը peering-ի ակնարկում նկարագրված է որպես peering-ից տարբերվող միացման տեսակ։

Եղե՛ք նույնքան զգույշ հակառակ ուղղությամբ։ «Մեզ պետք է գաղտնագրում VNet-երի միջև» հաճախ բավարարվում է աշխատանքային բեռի սեփական TLS-ով, և այդ ժամանակ դարպասը ծախս է՝ առանց դրա հետևում պահանջի։ Գրե՛ք այն նախադասությունը, որը կկարդա աուդիտորը, մինչև մեխանիզմ ընտրելը։

Պայման 2. տոպոլոգիան ուղի՞ղ է, թե՞ ինչ-որ բան պետք է անցնի:

Peering-ը անցողական չէ։ Հանգույցին peered երկու VNet-երը դրանով միմյանց միացած չեն, և մի ուղղությամբ աշխատող թվացող երթուղին սովորաբար այն peering-ն է, որը Connected-ի հասել է միայն մի կողմից։ Երկու կողմերն էլ պետք է գոյություն ունենան և երկուսն էլ ցույց տան Connected, և դա առաջինն է, ինչ ստուգում եք, երբ տրաֆիկը լուռ անհետանում է։

Եթե պահանջը տեղային ցանցին հասնելն է հանգույցի միջոցով, դարպասի անցումը առանձին ձևավորում է՝ հատուկ դերերով. հանգույցը տիրապետում է դարպասին, spoke-ի peering-ը թույլ է տալիս դարպասի անցում, իսկ spoke-ը պետք է թույլ տա փոխանցված տրաֆիկը։ Սրանք peering-ի հատկություններ են, ոչ թե VNet-երը միացնելու ինքնաշխատ հետևանքներ:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Արդյունավետ երթուղիների աղյուսակը «կա՞ արդյոք ուղին» հարցի ազնիվ պատասխանն է։ Այն ցույց է տալիս հաջորդ թռիչքի տեսակը, որն իրականում կօգտագործի հարթակը, ուստի կարգավորված թվացող, բայց չմիացված peering-ը հայտնվում է որպես բացակայող կամ սխալ երթուղի, ոչ թե առեղծված։

Պայման 3. ով է տիրապետում անցողական ուղուն և հաշվին:

Յուրաքանչյուր լրացուցիչ թռիչք ունի տեր։ Peering-ի դեպքում նոր VNet-ը նշանակում է նոր peering զույգ երկու կողմերում, իսկ անցման համար՝ հանգույց, որը շարունակում է փոխանցել տրաֆիկը, և երթուղիների աղյուսակ, որը շարունակում է մատնանշել այն։ VPN-ի դեպքում նոր VNet-ը նշանակում է ևս մեկ դարպաս կամ ևս մեկ միացում գոյություն ունեցողի վրա՝ իր հզորության առաստաղով, որը պետք է հետևել:

Ծախսը հետևում է նույն ձևին, բայց ոչ նույն հոդվածներին. peering-ի վճարները միացումն ու տվյալների փոխանցումն են, մինչդեռ VPN-ն ավելացնում է դարպասի ժամեր և իր փոխանցման վճարները։ Համեմատե՛ք այն տոպոլոգիայի ընդհանուր գումարը, որը դուք իրականում կշահագործեք մեկ տարի՝ ներառյալ երկրորդ թունելը և վերահսկողությունը, ոչ թե այսօրվա մեկ միացման գինը։ Ներառե՛ք այն աշխատանքը, որը ոչ ոք չի հաշվարկում. ինչ-որ մեկը պետք է պտտի բանալիները, հետևի թունելի վիճակին և պատասխանի ահազանգին գիշերվա ժամը երեքին, երբ դարպասը վերագործարկվում է։ Սովորաբար հենց այս հոդվածն է որոշում վեճը, որովհետև այն միակն է, որը երբեք չի հայտնվում առաջարկի մեջ:

Ինչն էլ ընտրեք, փորձարկե՛ք երեք հոսք՝ նախատեսվածը, մերժվածը, որը պետք է մերժված մնա, և վերականգնման դեպքը, երբ հանգույցի դարպասը կամ peering-ը անջատված է։ Մոդելը, որը բացատրում է միայն երջանիկ ուղին, չի ստուգվել, այն ցուցադրվել է:

Ստուգե՛ք ընտրությունը իր իսկ պնդման դեմ

Գրե՛ք մեկ նախադասություն, որը նշում է մոդելը, սահմանը և տիրոջը, ապա ստուգե՛ք, որ տեղակայված վիճակը համապատասխանում է դրան։ Peering-ի համար դա նշանակում է, որ երկու peering վիճակներն էլ Connected են, արդյունավետ երթուղին ցույց է տալիս peering-ի հաջորդ թռիչքը նպատակային նախածանցի համար, և ուղու վրա դարպաս չկա։ VNet-ից VNet VPN-ի համար դա նշանակում է, որ երկու միացումներն էլ Connected են, բանալիներն ու քաղաքականությունները համընկնում են երկու դարպասներում, և երթուղու հաջորդ թռիչքը վիրտուալ ցանցի դարպասն է:

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