AWS-ից Azure կայք-կայք VPN. սկզբում գրեք վերադարձի երթուղին
Երկու ամպերի միջև միացված թունելը ոչինչ չի ապացուցում, քանի դեռ յուրաքանչյուր աշխատանքային ենթացանց չի երթուղում հեռավոր նախածանցին։ Անցեք պլանը հերթականությամբ, ապա փորձարկեք ծառայությունը։
Թունելը կբարձրանա։ Սովորաբար այդպես է լինում, որովհետև IKE-ին պետք են միայն համապատասխան առաջարկներ և հասանելի գործընկերոջ հասցե։ Այն, ինչ հետո ձախողվում է, վերադարձի ուղին է. AWS-ի աշխատանքային բեռը փաթեթներ է ուղարկում թունել, բայց Azure-ի կողմում ոչ ոք չգիտի, թե ինչպես պատասխանել 10.10.0.0/16-ին, կամ Azure-ի երթուղին գտնվում է աղյուսակում, որը աշխատանքային ենթացանցը չի օգտագործում։ Գրեք երթուղիների պլանը նախքան որևէ կոնսոլի դիպչելը, և թունելը կդառնա աշխատանքի ամենաքիչ հետաքրքիր մասը։
Քայլ 1. սառեցրեք հասցեների պլանը
Աշխատեք կոնկրետ արժեքներով։ AWS-ի աշխատանքային բեռը գտնվում է 10.10.1.20 հասցեում 10.10.0.0/16-ի ներսում և պահանջում է TCP 443 դեպի Azure-ի ծառայություն 10.20.1.30 հասցեում 10.20.0.0/16-ի ներսում։ Երկու տիրույթները չպետք է համընկնեն, և ընդունման թեստը ծառայությունների զույգն է, ոչ թունելը։
Գրեք այդ չորս փաստերը ամեն ինչից առաջ, որովհետև յուրաքանչյուր հաջորդ քայլ ստուգվում է դրանց դեմ։
Քայլ 2. անվանեք դարպասը, որին պատկանում է յուրաքանչյուր ծայրը
AWS Site-to-Site VPN-ը կարող է ավարտվել վիրտուալ մասնավոր դարպասում կամ տրանզիտ դարպասում, և դրանք տարբեր երթուղավորման սեփականատերեր են։ Azure-ը առաջարկում է իր կառավարվող VPN Gateway-ը և առանձին՝ VM-ի վրա հիմնված սարքեր, որոնք հաճախորդներն իրենք են շահագործում։ Գրանցեք, թե որ զույգն ունեք, որովհետև հաջորդ ցատկը տարբերվում է յուրաքանչյուր համակցությունում։
Կառավարվող դարպասի համար մի պատճենեք երթուղի, որը ցույց է տալիս ենթադրյալ մասնավոր սարքի հասցեին։ Սարքի համար մի ենթադրեք, որ ամպում երթուղիների տարածումը կարգավորում է հյուր օպերացիոն համակարգը, որովհետև այն դա չի անում։
Այստեղ սխալվելը տալիս է պլան, որը ամբողջական է թվում և փաթեթներն ուղարկում է հասցե, որը երբեք չի պատասխանում։
Քայլ 3. գրեք այն երթուղին, որն իսկապես օգտագործում է յուրաքանչյուր աշխատանքային բեռ
Ստորև յուրաքանչյուր սահման առանձին որոնում է, և դրանցից մեկի երթուղին փաթեթի համար երթուղի չէ։ Լրացրեք աղյուսակը ձեր արժեքներով նախքան թունելը գործարկվելը։
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-ում աշխատանքային ենթացանցի երթուղիների աղյուսակը ձերն է թարմացնելու համար նույնիսկ այն բանից հետո, երբ BGP-ն կամ թունելը առողջ է. երթուղավորման ակնարկը դա համարում է կապի մաս։ Azure-ում օգտագործողի կողմից սահմանված երթուղիների աղյուսակը կապվում է ենթացանցի, ոչ թե վիրտուալ ցանցի հետ, ուստի արդյունավետ երթուղին ստուգեք աշխատանքային բեռի NIC-ում, ոչ VNet բլեյդում։
Կառավարվող Azure դարպասը կարող է սովորել հեռավոր նախածանցը դարպասի տարածման միջոցով, և UDR-ը կարող է վերացնել այդ որոշումը։ Ավելացրեք UDR-ը, երբ պատճառ ունեք, ոչ թե ռեֆլեքսով։ Եթե ավելացնեք, ուղղեք այն հաջորդ ցատկին, որը դարպասը հրապարակում է VPN ուղու համար, փոխարենը սարքի հասցե հորինելու։ Այնուհետև նորից կարդացեք արդյունավետ երթուղիները NIC-ում, որովհետև որոշումը իրականում կայացվում է այնտեղ։
Քայլ 4. համաձայնեցրեք ծավալը
BGP-ի համար համեմատեք, թե ինչ է հայտարարում յուրաքանչյուր կողմը, այն բանի հետ, ինչ մյուս կողմն իրականում սովորել է, նախածանց առ նախածանց։ Ստատիկ երթուղավորման համար համեմատեք կարգավորված հեռավոր տիրույթները քայլ 3-ում գրած աշխատանքային երթուղիների հետ։
Կրիպտոգրաֆիայի շուրջ համաձայնած IKE հարաբերությունը ապացույց չէ, որ որևէ կողմ սովորել է 10.10.0.0/16 կամ 10.20.0.0/16։ Երկու թունել կարող են բարձրացած լինել, մինչ մի կողմը հայտարարում է մեկ /24 ձեր պլանավորած /16-ի փոխարեն։ Ստուգեք նախածանցը երթուղիների աղյուսակում, ոչ թունելի կարգավիճակում։ Անհամապատասխանությունը հետո ի հայտ է գալիս որպես մեկ աշխատող և մեկ երբեք չպատասխանող ենթացանց։
Քայլ 5. փորձարկեք ծառայությունը իրական աղբյուրից
Թույլատրեք նախատեսված հոսքը AWS անվտանգության խմբերում և ցանցային ACL-ներում, Azure NSG-ներում և ուղու ցանկացած սարքային զտիչում։ Ապա բացեք մեկ կապ 10.10.1.20-ից հաստատված ծառայության հասցեին և պորտին և հաստատեք, որ պատասխանը վերադառնում է նույն աղբյուրին։
Ե՛վ ամպի անվտանգության խմբերը, և՛ NSG-ները վիճակային են, ուստի մերժված վերադարձի փաթեթը երթուղավորման ախտանիշ է, ոչ թե կանոն, որը մոռացել եք հակառակ ուղղությամբ գրել։
Որևէ դարպասից ping-ը ոչինչ չի լուծում։ Դարպասի հասցեին ICMP-ն վարժեցնում է կառավարման հարթության ուղին, ոչ թե փոխանցված TCP ծառայությունը, որն անհրաժեշտ է աշխատանքային բեռին։
Հետադարձ և գրառումներ
Գրանցեք երթուղիների սեփականատերերին թունելի նույնացուցիչների կողքին և պահպանեք փոփոխությունից առաջ երթուղիների աղյուսակները։ Եթե փոփոխությունը պետք է հանվի, հեռացրեք աշխատանքային երթուղիները նախքան թունելը քանդելը, որպեսզի ոչ մի ենթացանց չմնա ցույց տալով հաջորդ ցատկին, որն այլևս գոյություն չունի։
Այն ժամանակ ենթացանցի հետագա տեղափոխումը կամ spoke-ի միացումը ունի թարմացման մեկ սահմանված տեղ, փոխարենը աշխատող թունելի, որը կրում է մեղքը երթուղու համար, որը երբեք իրենը չի եղել։