Inspekce NVA v Azure: proč odpověď prochází jiným firewallem

Tok z pobočky do Azure může být směrován správně v obou směrech a přesto selhat, protože oba směry procházejí různými zařízeními. Požadavek opouští pobočku přes VPN, dosedne na NVA A a dosáhne pracovní zátěže. Odpověď opouští pracovní zátěž, odpovídá trase ukazující na NVA B a tam umírá. Každá trasa na tom obrázku je platná a relace TCP je přesto přerušená.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Tato mezera je tu celé téma: konvergence směrování a vlastnictví stavu relace jsou různé problémy, které na diagramu vypadají stejně.

Co Route Server skutečně programuje

Azure Route Server navazuje peering s podporovanými BGP mluvčími, učí se jejich trasy a programuje je do efektivních tras virtuální sítě. To je práce řídicí roviny. Nečte tabulku relací firewallu od dodavatele a netuší, které zařízení připustilo dané spojení. Dva následující skoky se stejnou cenou jsou pro tuto tkaninu prostě dva způsoby, jak dosáhnout stejného prefixu, a použije kterýkoli z nich.

Naučení trasy tedy dokazuje dosažitelnost. Nedokazuje nic o tom, zda zařízení na druhém konci tento tok už někdy vidělo.

Přečtěte si oba směry, než začnete navrhovat

Začněte tím, že si zapíšete směrování, které v každém směru skutečně máte, ne to, které jste zamýšleli. Konkrétnější trasy BGP, trasy definované uživatelem a chování brány spolu soutěží a vítěz se rozhoduje pro každé cílové místo, ne pro každou relaci. Výchozí trasa na NVA neznamená, že přes ni prochází každý privátní prefix.

Užitečná kontrola je zeptat se u jedné konkrétní IP pracovní zátěže, na který následující skok se každý směr přeloží. Pokud jsou odpovědí dvě různá zařízení, máte problém s asymetrií, ať už se projevil, nebo ne.

Kde stav žije

Stavový firewall připustí spojení a drží záznam v tabulce s klíčem pětice. Odpověď musí dorazit k zařízení, které tento záznam drží, nebo si toto zařízení musí stav opatřit jinak. Nic v datové rovině Azure záznam mezi zařízeními nepředává. Buď je provoz směrován zpět k vlastníkovi, nebo zařízení sdílejí stav prostřednictvím mechanismu dodavatele, nebo návrh nefunguje.

Proto dva zdravé NVA nejsou zdravotní kontrolou pro inspekci. Zdraví je o dosažitelnosti; inspekce je o tom, která instance drží relaci.

Podporované modely HA a co který slibuje

Microsoft's guidance on záměru směrování Virtual WAN popisují omezené chování pro dvourolové propojení a firewallové NVA, kde přímé směrování může obejít běžné symetrické vynucování hubu. Čtěte ty poznámky jako omezení zvolené topologie, ne jako zákaz aktivně-aktivních návrhů. Pár od dodavatele, který synchronizuje stav nebo směruje po tocích, může být podporován. Pár se stejnou cenou, který nedělá ani jedno, ne.

Potom definujte, co se stane se stávajícími relacemi, když uzel selže. Konvergence tras obnoví dosažitelnost pro nové toky během sekund, zatímco starý stav firewallu prostě zmizí. Opětovné připojení klienta může být dokumentovaným výsledkem a to je rozhodnutí, které je třeba udělat před incidentem, ne během něj.

Co otestovat, než tomu budete věřit

Test with inspection enabled and zásadou přístupu pracovní zátěže na místě, protože kterákoli z nich může asymetrii skrýt. Pošlete nový povolený tok v obou směrech a potvrďte, že stejné zařízení vidělo obě poloviny. Potom spusťte trvalý provoz a spusťte schválený failover a sledujte, zda zavedené relace přežijí, nebo se obnoví.

Korelujte každý tok se zařízením, které jej zpracovalo. Zachycení paketů na jednom NVA vám neřekne téměř nic, pokud se odpověď nikdy nevrátila.

Nakonec napište plán jako tři samostatné řádky: vlastnictví tras, směrování provozu a vlastnictví stavu relace. Návrhy se lámou, když jsou první dvě vyřešeny a třetí se předpokládá.