Site-to-Site VPN tarp AWS ir Azure: pirmiausia parašykite grąžinimo maršrutą
Sujungtas debesų tunelis nieko neįrodo, kol kiekvienas darbo krūvio potinklis nesiunčia maršrutu į tolimą prefiksą. Atlikite planą iš eilės, tada išbandykite paslaugą.
Tunelis pakils. Paprastai taip ir būna, nes IKE tereikia atitinkančių pasiūlymų ir pasiekiamo partnerio adreso. Kas po to nepavyksta – tai grąžinimo kelias: AWS darbo krūvis siunčia paketus į tunelį, bet Azure pusėje niekas nežino, kaip atsakyti į 10.10.0.0/16, arba Azure maršrutas yra lentelėje, kurios darbo krūvio potinklis nenaudoja. Parašykite maršrutų planą prieš liesdami bet kurią konsolę, ir tunelis taps mažiausiai įdomia darbo dalimi.
1 žingsnis: užšaldykite adresų planą
Dirbkite su konkrečiomis reikšmėmis. AWS darbo krūvis yra 10.10.1.20 adresu 10.10.0.0/16 viduje ir jam reikia TCP 443 į Azure paslaugą 10.20.1.30 adresu 10.20.0.0/16 viduje. Du diapazonai neturi persidengti, o priėmimo testas yra paslaugų pora, ne tunelis.
Užrašykite tuos keturis faktus prieš viską kita, nes kiekvienas vėlesnis žingsnis tikrinamas pagal juos.
2 žingsnis: įvardykite šliuzą, kuriam priklauso kiekvienas galas
AWS Site-to-Site VPN gali baigtis virtualiame privačiame šliuze arba tranzitiniame šliuze, ir tai yra skirtingi maršrutizavimo savininkai. Azure siūlo savo valdomą VPN Gateway ir atskirai VM pagrindu veikiančius įrenginius, kuriuos klientai valdo patys. Užsirašykite, kuri pora pas jus yra, nes kitas šuolis kiekvienoje kombinacijoje skiriasi.
Valdomam šliuzui nekopijuokite maršruto, nukreipto į spėjamą privatų įrenginio adresą. Įrenginiui nepamanykite, kad maršrutų sklaida debesyje sukonfigūruoja svečio operacinę sistemą, nes ji to nedaro.
Čia suklydus gaunamas planas, kuris atrodo išsamus ir siunčia paketus adresu, kuris niekada neatsako.
3 žingsnis: parašykite maršrutą, kurį kiekvienas darbo krūvis tikrai naudoja
Kiekviena toliau nurodyta riba yra atskira paieška, o maršrutas vienoje iš jų nėra paketo maršrutas. Užpildykite lentelę savo reikšmėmis prieš tuneliui pradedant veikti.
| 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 darbo krūvio potinklio maršrutų lentelę atnaujinti tenka jums net po to, kai BGP ar tunelis yra sveiki; maršrutizavimo apžvalga tai laiko ryšio dalimi. Azure naudotojo apibrėžtų maršrutų lentelė susiejama su potinkliu, o ne su virtualiuoju tinklu, todėl efektyvų maršrutą tikrinkite darbo krūvio NIC, o ne VNet juostoje.
Valdomas Azure šliuzas gali išmokti tolimą prefiksą per šliuzo sklaidą, o UDR gali tą sprendimą panaikinti. UDR pridėkite, kai turite priežastį, o ne refleksiškai. Jei pridedate, nukreipkite jį į kitą šuolį, kurį šliuzas skelbia VPN keliui, o ne išgalvokite įrenginio adresą. Tada dar kartą perskaitykite efektyvius maršrutus NIC, nes sprendimas iš tikrųjų priimamas ten.
4 žingsnis: suderinkite apimtį
BGP atveju palyginkite, ką skelbia kiekviena pusė, su tuo, ko kita pusė iš tikrųjų išmoko, prefiksas po prefikso. Statinio maršrutizavimo atveju palyginkite sukonfigūruotus tolimus diapazonus su 3 žingsnyje parašytais darbo krūvio maršrutais.
IKE ryšys, sutaręs dėl kriptografijos, nėra įrodymas, kad kuri nors pusė išmoko 10.10.0.0/16 ar 10.20.0.0/16. Du tuneliai gali būti pakilę, kol viena pusė skelbia vieną /24 vietoj suplanuoto /16. Tikrinkite prefiksą maršrutų lentelėje, o ne tunelio būsenoje. Nesutapimas vėliau pasirodo kaip vienas veikiantis ir vienas niekada neatsakantis potinklis.
5 žingsnis: išbandykite paslaugą iš tikrojo šaltinio
Leiskite numatytą srautą AWS saugos grupėse ir tinklo ACL, Azure NSG ir bet kuriame kelyje esančiame įrenginio filtre. Tada atidarykite vieną ryšį iš 10.10.1.20 į patvirtintą paslaugos adresą ir prievadą ir patvirtinkite, kad atsakymas grįžta į tą patį šaltinį.
Ir debesų saugos grupės, ir NSG yra būsenos, todėl atmestas grąžinimo paketas yra maršrutizavimo simptomas, o ne taisyklė, kurią pamiršote parašyti atvirkščiai.
Ping iš bet kurio šliuzo nieko neišsprendžia. ICMP į šliuzo adresą treniruoja valdymo plokštumos kelią, o ne perduodamą TCP paslaugą, kurios reikia darbo krūviui.
Atšaukimas ir įrašai
Užrašykite maršrutų savininkus šalia tunelio identifikatorių ir išsaugokite maršrutų lenteles iš laiko prieš pakeitimą. Jei pakeitimą reikia išimti, pašalinkite darbo krūvio maršrutus prieš ardydami tunelį, kad joks potinklis neliktų nukreiptas į kitą šuolį, kurio nebėra.
Tada vėlesnis potinklio perkėlimas ar spoke prijungimas turi vieną apibrėžtą vietą atnaujinti, o ne veikiantį tunelį, kuris neša kaltę už maršrutą, kuris niekada nebuvo jo.