Azure UDR դեպի VPN դարպաս. մեկ նպատակակետ, ոչ ամբողջ ելքը

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

Հաջորդ թռիչքը դարպաս է, ոչ սարքի IP

UDR-ը համապատասխան նախադասություն է ուղարկում հաջորդ թռիչքի տեսակին, և VirtualNetworkGateway-ը տեսակ է, ոչ հասցե։ Մարդիկ կպցնում են դարպասի մասնավոր IP-ն VirtualAppliance երթուղու մեջ և հետո զարմանում, թե ինչու ոչինչ չի համընկնում, քանի որ այդ տեսակը փոխարենը սպասում է NIC կամ ներքին բեռնվածքի հավասարեցուցիչ։ Microsoft-ի երթուղավորման փաստաթղթերը նույնպես սահմանափակում են դարպասի հաջորդ թռիչքը վիրտուալ ցանցով, որի դարպասը VPN դարպաս է։ ExpressRoute-ը, Route Server-ը և Virtual WAN հանգույցը այդ տարբերակով հասցեագրված չեն։

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

Կարդացեք գործող երթուղին նախքան որևէ բան փոխելը

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

Նախ նայեք գործող աղյուսակին, ապա որոշեք՝ երթուղի ավելացնո՞ւմ եք, թե՞ փոխարինում մեկը։

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

Գրեք երթուղին իրական նախադասության և ենթացանցի համաձայն

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

Ստեղծեք երթուղին, ապա կապեք աղյուսակը այն ենթացանցին, որտեղ գտնվում է աշխատանքային բեռնվածքը։

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Տարածումը նույնպես կարևոր է։ Երբ այդ աղյուսակում BGP տարածումը միացված է, սովորած նախադասությունները հայտնվում են ձեր գրածների կողքին, և ավելի կոնկրետ սովորած նախադասությունը կարող է հաղթել ավելի լայն UDR-ին։ Անջատեք տարածումը միայն այն ժամանակ, երբ ուզում եք, որ UDR հավաքածուն լինի հեղինակավոր այդ ենթացանցի համար։

Ավարտեք տեղական կեսը, այլապես հոսքը այնտեղ կմեռնի

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

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

Ընտրիչները և թույլատրելի ցուցակները առանձին են այս ամենից։ Azure-ի հաջորդ թռիչքի ընտրությունը չի լայնացնում VPN երթևեկության ընտրիչները և չի փոխում արտաքին ծառայության աղբյուրի թույլատրելի ցուցակը։

Ստուգեք նպատակակետի տեսած աղբյուրով

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

Ընտրված նախադասության միջոցով տրանզիտը շատ ավելի նեղ փոփոխություն է, քան հարկադրված թունելավորումը։ Պահեք այն նեղ, և հետ վերադարձը մեկ երթուղի ջնջելն է։