Inšpekcia NVA v Azure: prečo odpoveď prechádza iným firewallom

Tok z pobočky do Azure môže byť smerovaný správne v oboch smeroch a napriek tomu zlyhať, pretože oba smery prechádzajú cez rôzne zariadenia. Požiadavka opúšťa pobočku cez VPN, pristane na NVA A a dosiahne pracovné zaťaženie. Odpoveď opúšťa pracovné zaťaženie, zhoduje sa s trasou ukazujúcou na NVA B a tam zomiera. Každá trasa na tom obrázku je platná a relácia TCP je napriek tomu prerušená.

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

Táto medzera je tu celá téma: konvergencia smerovania a vlastníctvo stavu relácie sú rôzne problémy, ktoré na diagrame vyzerajú rovnako.

Čo Route Server skutočne programuje

Azure Route Server nadväzuje peering s podporovanými BGP hovorcami, učí sa ich trasy a programuje ich do efektívnych trás virtuálnej siete. Je to práca riadiacej roviny. Nečíta tabuľku relácií firewallu od dodávateľa a netuší, ktoré zariadenie pripustilo dané spojenie. Dva nasledujúce skoky s rovnakou cenou sú pre túto tkaninu jednoducho dva spôsoby, ako dosiahnuť rovnaký prefix, a použije ktorýkoľvek z nich.

Naučenie trasy teda dokazuje dostupnosť. Nedokazuje nič o tom, či zariadenie na druhej strane tento tok už niekedy videlo.

Prečítajte si oba smery, skôr než začnete navrhovať

Začnite tým, že si zapíšete smerovanie, ktoré v každom smere skutočne máte, nie to, ktoré ste zamýšľali. Konkrétnejšie trasy BGP, trasy definované používateľom a správanie brány spolu súťažia a víťaz sa rozhoduje pre každé cieľové miesto, nie pre každú reláciu. Predvolená trasa na NVA neznamená, že cez ňu prechádza každý privátny prefix.

Užitočná kontrola je opýtať sa pri jednej konkrétnej IP pracovného zaťaženia, na ktorý nasledujúci skok sa každý smer prekladá. Ak sú odpoveďou dve rôzne zariadenia, máte problém s asymetriou, či už sa prejavil, alebo nie.

Kde žije stav

Stavový firewall pripustí spojenie a drží záznam v tabuľke s kľúčom päťice. Odpoveď musí doraziť k zariadeniu, ktoré tento záznam drží, alebo si toto zariadenie musí stav zaobstarať inak. Nič v dátovej rovine Azure nepreposiela záznam medzi zariadeniami. Buď je prevádzka smerovaná späť k vlastníkovi, alebo zariadenia zdieľajú stav prostredníctvom mechanizmu dodávateľa, alebo návrh nefunguje.

Preto dve zdravé NVA nie sú zdravotnou kontrolou pre inšpekciu. Zdravie je o dostupnosti; inšpekcia je o tom, ktorá inštancia drží reláciu.

Podporované modely HA a čo ktorý sľubuje

Microsoft's guidance on zámeru smerovania Virtual WAN opisuje obmedzené správanie pre dvojrolové prepojenie a firewallové NVA, kde priame smerovanie môže obísť bežné symetrické presadzovanie hubu. Čítajte tie poznámky ako obmedzenia zvolenej topológie, nie ako zákaz aktívne-aktívnych návrhov. Pár od dodávateľa, ktorý synchronizuje stav alebo smeruje po tokoch, môže byť podporovaný. Pár s rovnakou cenou, ktorý nerobí ani jedno, nie.

Potom definujte, čo sa stane s existujúcimi reláciami, keď uzol zlyhá. Konvergencia trás obnoví dostupnosť pre nové toky v priebehu sekúnd, kým starý stav firewallu jednoducho zmizne. Opätovné pripojenie klienta môže byť dokumentovaným výsledkom a to je rozhodnutie, ktoré treba urobiť pred incidentom, nie počas neho.

Čo otestovať, kým tomu budete veriť

Test with inspection enabled and zásadou prístupu pracovného zaťaženia na mieste, pretože ktorákoľvek z nich môže asymetriu skryť. Pošlite nový povolený tok v oboch smeroch a potvrďte, že rovnaké zariadenie videlo obe polovice. Potom spustite trvalú prevádzku a spustite schválený failover a sledujte, či zavedené relácie prežijú alebo sa obnovia.

Korelujte každý tok so zariadením, ktoré ho spracovalo. Zachytenie paketov na jednom NVA vám nepovie takmer nič, ak sa odpoveď nikdy nevrátila tam.

Nakoniec napíšte plán ako tri samostatné riadky: vlastníctvo trás, smerovanie prevádzky a vlastníctvo stavu relácie. Návrhy sa lámu, keď sú prvé dve vyriešené a tretia sa predpokladá.