Site-to-Site VPN medzi AWS a Azure: najprv napíšte spiatočnú trasu

Tunel sa zdvihne. Zvyčajne áno, pretože IKE potrebuje len zodpovedajúce návrhy a dostupnú adresu partnera. Čo potom zlyhá, je spiatočná cesta: úloha v AWS posiela pakety do tunela, ale na strane Azure nikto nevie, ako odpovedať na 10.10.0.0/16, alebo trasa Azure je v tabuľke, ktorú podsiet úlohy nepoužíva. Napíšte plán trás skôr, než sa dotknete ktorejkoľvek konzoly, a tunel sa stane najmenej zaujímavou časťou práce.

Krok 1: zmrazte plán adries

Pracujte s konkrétnymi hodnotami. Úloha v AWS je na 10.10.1.20 v 10.10.0.0/16 a potrebuje TCP 443 k službe Azure na 10.20.1.30 v 10.20.0.0/16. Rozsahy sa nesmú prekrývať a akceptačným testom je dvojica služieb, nie tunel.

Zapíšte tieto štyri fakty pred všetkým ostatným, pretože každý ďalší krok sa overuje proti nim.

Krok 2: pomenujte bránu, ktorá vlastní každý koniec

AWS Site-to-Site VPN môže končiť na virtuálnej privátnej bráne alebo na tranzitnej bráne, a to sú rôzni vlastníci smerovania. Azure ponúka spravovanú VPN Gateway a oddelene zariadenia na báze VM, ktoré si zákazníci prevádzkujú sami. Zapíšte, ktorú dvojicu máte, pretože ďalší skok sa v každej kombinácii líši.

Pri spravovanej bráne nekopírujte trasu na odhadovanú adresu privátneho zariadenia. Pri zariadení nepredpokladajte, že propagácia trás v cloude nakonfiguruje hostovaný operačný systém, pretože to nerobí.

Chyba tu vytvorí plán, ktorý vyzerá úplne, a posiela pakety na adresu, ktorá nikdy neodpovie.

Krok 3: napíšte trasu, ktorú každá úloha skutočne používa

Každá hranica nižšie je samostatné hľadanie a trasa v jednej z nich nie je trasou pre paket. Vyplňte tabuľku vlastnými hodnotami, kým tunel naberie prevádzku.

V AWS je smerovacia tabuľka podsiety úlohy vaša na aktualizáciu aj potom, ako je BGP alebo tunel v poriadku; prehľad smerovania to považuje za súčasť pripojenia. V Azure sa tabuľka používateľsky definovaných trás priraďuje k podsieti, nie k virtuálnej sieti, preto overujte efektívnu trasu na NIC úlohy, nie v okne VNet.

Spravovaná brána Azure sa môže naučiť vzdialený prefix cez propagáciu brány a UDR môže toto rozhodnutie prepísať. UDR pridávajte, keď na to máte dôvod, nie reflexívne. Ak ju pridáte, nasmerujte ju na ďalší skok, ktorý brána zverejňuje pre cestu VPN, namiesto vymýšľania adresy zariadenia. Potom znova prečítajte efektívne trasy na NIC, pretože rozhodnutie sa v skutočnosti prijíma tam.

Krok 4: zosúlaďte rozsah

Pri BGP porovnajte, čo každá strana inzeruje, s tým, čo druhá strana skutočne naučila, prefix po prefixe. Pri statickom smerovaní porovnajte nakonfigurované vzdialené rozsahy s trasami úlohy, ktoré ste napísali v kroku 3.

Vzťah IKE, ktorý sa zhodne na kryptografii, nie je dôkazom, že niektorá strana sa naučila 10.10.0.0/16 alebo 10.20.0.0/16. Dva tunely môžu byť hore, kým jedna strana inzeruje jedinú /24 namiesto plánovanej /16. Prefíx kontrolujte v smerovacej tabuľke, nie v stave tunela. Nesúlad sa neskôr prejaví ako jedna fungujúca podsiet a jedna, ktorá nikdy neodpovie.

Krok 5: otestujte službu zo skutočného zdroja

Povoľte zamýšľaný tok v bezpečnostných skupinách a sieťových ACL AWS, v NSG Azure a v akomkoľvek filtri zariadenia na ceste. Potom otvorte jedno spojenie z 10.10.1.20 na schválenú adresu a port služby a potvrďte, že odpoveď sa vracia k rovnakému zdroju.

Bezpečnostné skupiny v cloude aj NSG sú stavové, takže odmietnutý spiatočný paket je príznakom smerovania, nie pravidla, ktoré ste zabudli napísať opačne.

Ping z ktorejkoľvek brány nič nerozhodne. ICMP na adresu brány precvičuje cestu riadiacej roviny, nie preposielanú TCP službu, ktorú úloha potrebuje.

Vrátenie a záznamy

Zapíšte vlastníkov trás vedľa identifikátorov tunela a uchovajte smerovacie tabuľky pred zmenou. Ak sa zmena musí vziať späť, odstráňte trasy úlohy pred zbúraním tunela, aby žiadna podsiet neukazovala na ďalší skok, ktorý už neexistuje.

Neskorší presun podsiety alebo pripojenie spoke tak má jedno určené miesto na aktualizáciu, namiesto fungujúceho tunela, ktorý nesie vinu za trasu, ktorú nikdy nevlastnil.