Site-to-Site VPN mezi AWS a Azure: nejdřív napište zpětnou trasu

Tunel se zvedne. Obvykle ano, protože IKE potřebuje jen odpovídající návrhy a dostupnou adresu protistrany. Co pak selže, je zpětná cesta: úloha v AWS posílá pakety do tunelu, ale na straně Azure nikdo neví, jak odpovědět na 10.10.0.0/16, nebo trasa Azure existuje v tabulce, kterou podsíť úlohy nepoužívá. Napište plán tras dřív, než se dotknete kterékoli konzole, a tunel se stane nejméně zajímavou částí práce.

Krok 1: zmrazte plán adres

Pracujte s konkrétními hodnotami. Úloha v AWS je na 10.10.1.20 uvnitř 10.10.0.0/16 a potřebuje TCP 443 ke službě Azure na 10.20.1.30 uvnitř 10.20.0.0/16. Rozsahy se nesmějí překrývat a akceptačním testem je dvojice služeb, ne tunel.

Zapište tyto čtyři skutečnosti především ostatním, protože každý další krok se proti nim ověřuje.

Krok 2: pojmenujte bránu, která vlastní každý konec

AWS Site-to-Site VPN může končit na virtuální privátní bráně nebo na tranzitní bráně, a to jsou různí vlastníci směrování. Azure nabízí spravovanou VPN Gateway a odděleně zařízení na bázi VM, která si zákazníci provozují sami. Zapište, kterou dvojici máte, protože další skok se v každé kombinaci liší.

U spravované brány nekopírujte trasu na odhadovanou adresu privátního zařízení. U zařízení nepředpokládejte, že propagace tras v cloudu nakonfiguruje hostovaný operační systém, protože to nedělá.

Chyba zde vytvoří plán, který vypadá úplně, a posílá pakety na adresu, která nikdy neodpoví.

Krok 3: napište trasu, kterou každá úloha skutečně používá

Každá hranice níže je samostatné hledání a trasa v jedné z nich není trasou pro paket. Vyplňte tabulku vlastními hodnotami, než tunel naběhne.

V AWS je směrovací tabulka podsítě úlohy vaše k aktualizaci i poté, co je BGP nebo tunel v pořádku; přehled směrování to považuje za součást připojení. V Azure se tabulka uživatelsky definovaných tras přidružuje k podsíti, nikoli k virtuální síti, takže ověřujte efektivní trasu na NIC úlohy, ne v okně VNet.

Spravovaná brána Azure se může naučit vzdálený prefix přes propagaci brány a UDR může toto rozhodnutí přebít. UDR přidávejte, když k tomu máte důvod, ne reflexivně. Pokud ji přidáte, nasměrujte ji na další skok, který brána publikuje pro cestu VPN, místo vymýšlení adresy zařízení. Potom znovu přečtěte efektivní trasy na NIC, protože rozhodnutí se skutečně děje tam.

Krok 4: sladěte rozsah

U BGP porovnejte, co každá strana inzeruje, s tím, co druhá strana skutečně naučila, prefix po prefixu. U statického směrování porovnejte nakonfigurované vzdálené rozsahy s trasami úlohy, které jste napsali v kroku 3.

Vztah IKE, který se shodne na kryptografii, není důkazem, že některá strana naučila 10.10.0.0/16 nebo 10.20.0.0/16. Dva tunely mohou být nahoru, zatímco jedna strana inzeruje jednu /24 místo /16, kterou jste plánovali. Zkontrolujte prefix ve směrovací tabulce, ne ve stavu tunelu. Nesoulad se později projeví jako jedna fungující podsíť a jedna, která nikdy neodpoví.

Krok 5: otestujte službu ze skutečného zdroje

Povolte zamýšlený tok v bezpečnostních skupinách a síťových ACL AWS, v NSG Azure a v jakémkoli filtru zařízení na cestě. Potom otevřete jedno spojení z 10.10.1.20 na schválenou adresu a port služby a potvrďte, že odpověď se vrací ke stejnému zdroji.

Bezpečnostní skupiny v cloudu i NSG jsou stavové, takže odmítnutý zpětný paket je příznakem směrování, ne pravidla, které jste zapomněli napsat opačně.

Ping z kterékoli brány nic nevyřeší. ICMP na adresu brány procvičuje cestu řídicí roviny, ne předávanou TCP službu, kterou úloha potřebuje.

Vrácení zpět a záznamy

Zapište vlastníky tras vedle identifikátorů tunelu a uchovejte směrovací tabulky před změnou. Pokud je třeba změnu vyndat, odstraňte trasy úlohy před stržením tunelu, aby žádná podsíť neukazovala na další skok, který už neexistuje.

Pozdější přesun podsítě nebo připojení spoke pak má jedno určené místo pro aktualizaci, místo fungujícího tunelu, který nese vinu za trasu, kterou nikdy nevlastnil.