Azure NVA-inspectie: waarom het antwoord via een andere firewall loopt

Een flow van de vestiging naar Azure kan in beide richtingen correct gerouteerd zijn en toch mislukken, omdat de twee richtingen verschillende apparaten nemen. Het verzoek verlaat de vestiging via de VPN, landt op NVA A en bereikt de workload. Het antwoord verlaat de workload, matcht een route die naar NVA B wijst en sterft daar. Elke route in dat beeld is geldig, en de TCP-sessie is nog steeds gebroken.

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

Dat gat is hier het hele onderwerp: routeconvergentie en eigenaarschap van sessiestatus zijn verschillende problemen die er in een diagram identiek uitzien.

Wat Route Server werkelijk programmeert

Azure Route Server peert met ondersteunde BGP-sprekers, leert hun routes en programmeert ze in de effectieve routes van het virtuele netwerk. Dat is een controlevlaktaak. Het leest geen sessietabel van een leveranciersfirewall en weet niet welk apparaat een bepaalde verbinding heeft toegelaten. Twee volgende hops met gelijke kosten zijn voor dit fabric simpelweg twee manieren om hetzelfde prefix te bereiken, en het gebruikt er een van.

Een route leren bewijst dus bereikbaarheid. Het bewijst niets over de vraag of het apparaat aan de andere kant deze flow al eerder heeft gezien.

Lees beide richtingen voordat u ontwerpt

Begin met het opschrijven van de sturing die u werkelijk in elke richting hebt, niet die u bedoelde. Specifiekere BGP-routes, door de gebruiker gedefinieerde routes en gatewaygedrag concurreren allemaal, en de winnaar wordt per bestemming bepaald, niet per sessie. Een standaardroute op de NVA betekent niet dat elk privé-prefix erdoor gaat.

Een nuttige controle is om voor één specifiek workload-IP te vragen naar welke volgende hop elke richting oplost. Als het antwoord twee verschillende apparaten zijn, hebt u een asymmetrieprobleem, of het zich al heeft geopenbaard of niet.

Waar de status woont

Een stateful firewall laat een verbinding toe en houdt een tabelvermelding bij met sleutel op de vijf-tuple. Het antwoord moet het apparaat bereiken dat die vermelding heeft, of dat apparaat moet de status op een andere manier verkrijgen. Niets in het Azure-datavlak stuurt de vermelding tussen apparaten door. Of het verkeer wordt terug naar de eigenaar gestuurd, of de apparaten delen status via een leveranciersmechanisme, of het ontwerp werkt niet.

Daarom zijn twee gezonde NVA’s geen gezondheidscontrole voor inspectie. Gezondheid gaat over bereikbaarheid; inspectie gaat over welke instantie de sessie heeft.

Ondersteunde HA-modellen en wat elk belooft

Microsoft's guidance on de routeringsintentie van Virtual WAN beschrijven beperkt gedrag voor dual-role-connectiviteit en firewall-NVA’s, waarbij directe routering de normale symmetrische handhaving van de hub kan omzeilen. Lees die notities als beperkingen op de gekozen topologie, niet als een verbod op actief-actief-ontwerpen. Een leverancierspaar dat status synchroniseert, of per flow stuurt, kan worden ondersteund. Een paar met gelijke kosten dat geen van beide doet, niet.

Definieer vervolgens wat er met bestaande sessies gebeurt als een node uitvalt. Routeconvergentie herstelt de bereikbaarheid voor nieuwe flows binnen seconden, terwijl de oude firewallstatus gewoon weg is. Een client-herverbinding kan het gedocumenteerde resultaat zijn, en dat is een beslissing vóór het incident, niet tijdens.

Wat u moet testen voordat u erop vertrouwt

Test with inspection enabled and het toegangsbeleid van de workload op zijn plaats, omdat een van beide de asymmetrie kan verbergen. Stuur een nieuwe geautoriseerde flow in beide richtingen en bevestig dat hetzelfde apparaat beide helften heeft gezien. Draai daarna aanhoudend verkeer en activeer de goedgekeurde failover, en kijk of bestaande sessies overleven of opnieuw verbinden.

Correleer elke flow met het apparaat dat hem heeft afgehandeld. Een packet capture op één NVA vertelt u bijna niets als het antwoord daar nooit terugkwam.

Schrijf het plan ten slotte als drie afzonderlijke regels: eigenaarschap van routes, sturing van verkeer en eigenaarschap van sessiestatus. Ontwerpen breken wanneer de eerste twee zijn opgelost en de derde wordt aangenomen.