Azure NVA-inspeksjon: hvorfor svaret går gjennom en annen brannmur

En flyt fra filialen til Azure kan rutes riktig i begge retninger og likevel mislykkes, fordi de to retningene bruker forskjellige apparater. Forespørselen forlater filialen over VPN, lander på NVA A og når arbeidsbelastningen. Svaret forlater arbeidsbelastningen, treffer en rute som peker på NVA B og dør der. Hver rute i det bildet er gyldig, og TCP-sesjonen er fortsatt brutt.

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

Det gapet er hele emnet her: rutekonvergens og eierskap til sesjonstilstand er forskjellige problemer som ser identiske ut i et diagram.

Hva Route Server faktisk programmerer

Azure Route Server peeringer med støttede BGP-talere, lærer rutene deres og programmerer dem inn i det virtuelle nettverkets effektive ruter. Det er en kontrollplanoppgave. Den leser ikke en leverandørbrannmurs sesjonstabell og aner ikke hvilket apparat som slapp en gitt tilkobling inn. To neste hopp med lik kostnad er, for dette stoffet, rett og slett to måter å nå samme prefiks på, og den vil bruke en av dem.

Å lære en rute beviser derfor nåbarhet. Det beviser ingenting om hvorvidt enheten i andre enden har sett denne flyten før.

Les begge retninger før du designer

Begynn med å skrive ned styringen du faktisk har i hver retning, ikke den du hadde tenkt. Mer spesifikke BGP-ruter, brukerdefinerte ruter og gatewayatferd konkurrerer alle, og vinneren avgjøres per destinasjon, ikke per sesjon. En standardrute på NVA betyr ikke at hvert private prefiks går gjennom den.

En nyttig kontroll er å spørre, for én bestemt arbeidsbelastnings-IP, hvilket neste hopp hver retning løses til. Hvis svaret er to forskjellige apparater, har du et asymmetriproblem uansett om det har kommet til syne eller ikke.

Hvor tilstanden bor

En stateful brannmur slipper en tilkobling inn og holder en tabelloppføring med nøkkel på fem-tuplen. Svaret må nå enheten som holder oppføringen, eller enheten må skaffe tilstanden på annen måte. Ingenting i Azures dataplan videresender oppføringen mellom apparater. Enten styres trafikken tilbake til eieren, eller apparatene deler tilstand via en leverandørmekanisme, eller designet virker ikke.

Derfor er to sunne NVA-er ikke en helsesjekk for inspeksjon. Helse handler om nåbarhet; inspeksjon handler om hvilken instans som holder sesjonen.

Støttede HA-modeller og hva hver av dem lover

Microsoft's guidance on Virtual WAN-ruteintensjon beskriver begrenset atferd for dobbeltrolle-tilkobling og brannmur-NVA-er, der direkteruting kan omgå hubens normale symmetriske håndheving. Les disse notatene som begrensninger på topologien du valgte, ikke som et forbud mot aktiv-aktiv-design. Et leverandørpar som synkroniserer tilstand, eller styrer per flyt, kan støttes. Et par med lik kostnad som ikke gjør noen av delene, er ikke.

Definer så hva som skjer med eksisterende sesjoner når en node feiler. Rutekonvergens gjenoppretter nåbarheten for nye flyter innen sekunder, mens den gamle brannmurtilstanden rett og slett er borte. En klientgjenoppkobling kan være det dokumenterte resultatet, og det er en beslutning som tas før hendelsen, ikke under den.

Hva du bør teste før du stoler på det

Test with inspection enabled and arbeidsbelastningens tilgangspolicy på plass, fordi en av dem kan skjule asymmetrien. Send en ny autorisert flyt i begge retninger og bekreft at samme apparat så begge halvdeler. Kjør deretter vedvarende trafikk og utløs den godkjente failoveren, og se om etablerte sesjoner overlever eller kobler til på nytt.

Korrelér hver flyt med apparatet som håndterte den. En pakkefangst på én NVA forteller deg nesten ingenting hvis svaret aldri kom tilbake dit.

Til slutt skriver du planen som tre separate linjer: ruteneierskap, trafikkstyring og eierskap til sesjonstilstand. Design bryter sammen når de to første er løst og den tredje antas.