Azure NVA-inspektion: hvorfor svaret går gennem en anden firewall

Et flow fra filialen til Azure kan rutes korrekt i begge retninger og alligevel fejle, fordi de to retninger bruger forskellige apparater. Anmodningen forlader filialen over VPN, lander på NVA A og når arbejdsbelastningen. Svaret forlader arbejdsbelastningen, matcher en rute, der peger på NVA B, og dør der. Hver rute i det billede er gyldig, og TCP-sessionen er stadig brudt.

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

Det hul er hele emnet her: routingkonvergens og ejerskab af sessionstilstand er forskellige problemer, der ser identiske ud på et diagram.

Hvad Route Server faktisk programmerer

Azure Route Server peerer med understøttede BGP-talere, lærer deres ruter og programmerer dem ind i det virtuelle netværks effektive ruter. Det er et kontrolplan-arbejde. Den læser ikke en leverandørfirewalls sessionstabel og aner ikke, hvilket apparat der tillod en given forbindelse. To næste hop med samme omkostning er for dette stof blot to måder at nå samme præfiks på, og det vil bruge en af dem.

At lære en rute beviser derfor nåbarhed. Det beviser intet om, hvorvidt enheden i den anden ende har set dette flow før.

Læs begge retninger, før du designer

Begynd med at skrive den styring ned, du faktisk har i hver retning, ikke den, du havde tænkt dig. Mere specifikke BGP-ruter, brugerdefinerede ruter og gatewayadfærd konkurrerer alle, og vinderen afgøres pr. destination, ikke pr. session. En standardrute på NVA betyder ikke, at hvert privat præfiks går gennem den.

En nyttig kontrol er at spørge, for en bestemt arbejdsbelastnings-IP, hvilket næste hop hver retning opløses til. Hvis svaret er to forskellige apparater, har du et asymmetriproblem, uanset om det er kommet frem endnu.

Hvor tilstanden bor

En stateful firewall tillader en forbindelse og holder en tabelpost med nøgle på fem-tuplen. Svaret skal nå den enhed, der holder posten, eller enheden skal skaffe tilstanden på anden vis. Intet i Azures dataplan videresender posten mellem apparater. Enten styres trafikken tilbage til ejeren, eller apparaterne deler tilstand via en leverandørmekanisme, eller designet virker ikke.

Derfor er to sunde NVA’er ikke en sundhedskontrol for inspektion. Sundhed handler om nåbarhed; inspektion handler om, hvilken instans der holder sessionen.

Understøttede HA-modeller og hvad hver især lover

Microsoft's guidance on Virtual WAN-routingintent beskriver afgrænset adfærd for dobbeltrolle-konnektivitet og firewall-NVA’er, hvor direkte routing kan omgå hubens normale symmetriske håndhævelse. Læs disse noter som begrænsninger for den topologi, du valgte, ikke som et forbud mod aktiv-aktiv-design. Et leverandørpar, der synkroniserer tilstand eller styrer pr. flow, kan understøttes. Et par med samme omkostning, der ikke gør nogen af delene, er ikke.

Definer derefter, hvad der sker med eksisterende sessioner, når en node fejler. Routingkonvergens genopretter nåbarheden for nye flows inden for sekunder, mens den gamle firewalltilstand blot er væk. En klientgenopkobling kan være det dokumenterede resultat, og det er en beslutning, der træffes før hændelsen, ikke under den.

Hvad du skal teste, før du stoler på det

Test with inspection enabled and arbejdsbelastningens adgangspolitik på plads, fordi en af dem kan skjule asymmetrien. Send et nyt autoriseret flow i begge retninger, og bekræft, at samme apparat har set begge halvdele. Kør derefter vedvarende trafik, og udløs det godkendte failover, mens du ser, om etablerede sessioner overlever eller genopkobler.

Korrelér hvert flow med det apparat, der håndterede det. En pakkefangst på én NVA fortæller dig næsten intet, hvis svaret aldrig kom tilbage til den.

Til sidst skriver du planen som tre separate linjer: ruteejerskab, trafikstyring og ejerskab af sessionstilstand. Design går i stykker, når de to første er løst, og den tredje antages.