Site-to-site VPN mula AWS patungong Azure: isulat muna ang pabalik na ruta
Ang konektadong tunnel sa pagitan ng dalawang cloud ay walang pinapatunayan hanggang ang bawat subnet ng workload ay mag-ruta patungo sa malayong prefix. Sundin ang plano nang sunod-sunod, pagkatapos ay subukan ang serbisyo.
Aangat ang tunnel. Karaniwang nangyayari iyon, dahil kailangan lang ng IKE ang magkatugmang panukala at maabot na peer address. Ang bumabagsak pagkatapos ay ang pabalik na landas: ang workload sa AWS ay nagpapadala ng packet sa tunnel, ngunit walang nakakaalam sa panig ng Azure kung paano sasagutin ang 10.10.0.0/16, o ang ruta ng Azure ay nasa talahanayang hindi ginagamit ng subnet ng workload. Isulat ang plano ng ruta bago hawakan ang anumang console, at ang tunnel ang magiging pinakawalang-kabuluhang bahagi ng trabaho.
Hakbang 1: i-freeze ang plano ng address
Magtrabaho gamit ang konkretong halaga. Ang workload sa AWS ay nasa 10.10.1.20 sa loob ng 10.10.0.0/16 at kailangan ng TCP 443 patungo sa serbisyong Azure sa 10.20.1.30 sa loob ng 10.20.0.0/16. Hindi maaaring mag-overlap ang dalawang saklaw, at ang pagtanggap na pagsubok ay ang pares ng serbisyo, hindi ang tunnel.
Isulat ang apat na katotohanang iyon bago ang lahat, dahil bawat susunod na hakbang ay sinusuri laban sa mga ito.
Hakbang 2: pangalanan ang gateway na nagmamay-ari ng bawat dulo
Ang AWS Site-to-Site VPN ay maaaring magtapos sa virtual private gateway o transit gateway, at magkaibang may-ari ng routing ang mga ito. Nag-aalok ang Azure ng managed na VPN Gateway at, hiwalay, mga appliance na nakabatay sa VM na sila mismo ang nagpapatakbo. Itala kung aling pares ang mayroon ka, dahil iba ang susunod na hop sa bawat kombinasyon.
Para sa managed na gateway, huwag kopyahin ang rutang tumuturo sa hinulaang address ng pribadong appliance. Para sa appliance, huwag ipagpalagay na ang pagpapalaganap ng ruta sa cloud ay nagko-configure ng guest operating system, dahil hindi nito ginagawa iyon.
Ang pagkakamali dito ay gumagawa ng planong mukhang kumpleto at nagpapadala ng packet sa address na hindi kailanman sumasagot.
Hakbang 3: isulat ang rutang aktwal na ginagamit ng bawat workload
Ang bawat hangganan sa ibaba ay hiwalay na paghahanap, at ang ruta sa isa sa mga ito ay hindi ruta para sa packet. Punan ang talahanayan ng sarili mong halaga bago tumakbo ang tunnel.
| 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 |
Sa AWS, ang talahanayan ng ruta ng subnet ng workload ay sa iyo na i-update kahit matapos maging maayos ang BGP o tunnel; itinuturing ng pangkalahatang-tanaw ng routing iyon na bahagi ng koneksyon. Sa Azure, ang talahanayan ng rutang tinukoy ng user ay iniuugnay sa subnet sa halip na sa virtual network, kaya suriin ang epektibong ruta sa NIC ng workload at hindi sa blade ng VNet.
Ang managed na Azure gateway ay maaaring matutunan ang malayong prefix sa pamamagitan ng pagpapalaganap ng gateway, at ang UDR ay maaaring puksain ang desisyong iyon. Magdagdag ng UDR kapag may dahilan ka, hindi dahil sa ugali. Kung magdadagdag ka, ituro ito sa susunod na hop na inilalathala ng gateway para sa landas ng VPN sa halip na gumawa ng address ng appliance. Pagkatapos ay basahin muli ang epektibong ruta sa NIC, dahil doon talaga ginagawa ang desisyon.
Hakbang 4: itugma ang saklaw
Para sa BGP, ihambing ang inaanunsyo ng bawat panig sa aktwal na natutunan ng kabilang panig, prefix bawat prefix. Para sa static na routing, ihambing ang mga naka-configure na malayong saklaw sa mga ruta ng workload na isinulat mo sa hakbang 3.
Ang ugnayang IKE na nagkasundo sa cryptography ay hindi patunay na may panig na natutunan ang 10.10.0.0/16 o 10.20.0.0/16. Maaaring nakatayo ang dalawang tunnel habang ang isang panig ay nag-aanunsyo ng isang /24 lamang sa halip na ang /16 na pinlano mo. Suriin ang prefix sa talahanayan ng routing, hindi sa status ng tunnel. Ang pagkakaiba ay lumilitaw mamaya bilang isang gumaganang subnet at isa na hindi kailanman sumasagot.
Hakbang 5: subukan ang serbisyo, mula sa tunay na pinagmulan
Payagan ang nilalayong daloy sa mga security group at network ACL ng AWS, sa mga NSG ng Azure at sa anumang filter ng appliance sa landas. Pagkatapos ay buksan ang isang koneksyon mula 10.10.1.20 patungo sa aprubadong address at port ng serbisyo at kumpirmahin na bumabalik ang sagot sa parehong pinagmulan.
Parehong stateful ang mga security group ng cloud at ang mga NSG, kaya ang tinanggihang pabalik na packet ay sintomas ng routing, hindi isang panuntunang nakalimutan mong isulat sa kabaligtaran.
Ang ping mula sa anumang gateway ay walang napagpasyahan. Ang ICMP patungo sa address ng gateway ay nagsasanay sa landas ng control plane, hindi sa ipinasa na serbisyong TCP na kailangan ng workload.
Rollback at mga tala
Itala ang mga may-ari ng ruta sa tabi ng mga identifier ng tunnel, at itago ang mga talahanayan ng ruta bago ang pagbabago. Kung kailangang alisin ang pagbabago, tanggalin ang mga ruta ng workload bago gibain ang tunnel, upang walang subnet na maiwang tumuturo sa susunod na hop na wala na.
Pagkatapos, ang paglipat ng subnet o pagkakabit ng spoke sa hinaharap ay may isang tinukoy na lugar na aayusin, sa halip na isang gumaganang tunnel na nagdadala ng sisi sa rutang hindi naman nito pag-aari.