Azure NVA-inspeksjon: kvifor svaret går gjennom ein annan brannmur

Ein flyt frå filialen til Azure kan rutast riktig i begge retningar og likevel mislukkast, fordi dei to retningane brukar ulike apparat. Førespurnaden forlèt filialen over VPN, landar på NVA A og når arbeidslasta. Svaret forlèt arbeidslasta, treffer ei rute som peikar på NVA B og døyr der. Kvar rute i det bildet er gyldig, og TCP-sesjonen er framleis broten.

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

Det gapet er heile emnet her: rutekonvergens og eigarskap til sesjonstilstand er ulike problem som ser identiske ut i eit diagram.

Kva Route Server faktisk programmerer

Azure Route Server peeringar med støtta BGP-talarar, lærer rutene deira og programmerer dei inn i dei effektive rutene til det virtuelle nettet. Det er ein kontrollplanoppgåve. Han les ikkje sesjonstabellen til ein leverandørbrannmur og veit ikkje kva apparat som sleppte ei gitt tilkobling inn. To neste hopp med lik kostnad er, for dette stoffet, rett og slett to måtar å nå same prefiks på, og han vil bruke ein av dei.

Å lære ei rute beviser derfor nåbarheit. Det beviser ingenting om kvidan eininga i andre enden har sett denne flyten før.

Les begge retningar før du designar

Byrja med å skrive ned styringa du faktisk har i kvar retning, ikkje den du hadde tenkt. Meir spesifikke BGP-ruter, brukardefinerte ruter og gatewayåtferd konkurrerer alle, og vinnaren blir avgjord per destinasjon, ikkje per sesjon. Ei standardrute på NVA betyr ikkje at kvart private prefiks går gjennom ho.

Ein nyttig kontroll er å spørje, for éin bestemt arbeidslast-IP, kva neste hopp kvar retning blir løyst til. Viss svaret er to ulike apparat, har du eit asymmetriproblem uansett om det har kome til syne eller ikkje.

Kvar tilstanden bur

Ein stateful brannmur slepp ei tilkobling inn og held ei tabelloppføring med nøkkel på fem-tuplen. Svaret må nå eininga som held oppføringa, eller eininga må skaffe tilstanden på annan måte. Ingenting i dataplanet til Azure videresender oppføringa mellom apparat. Anten blir trafikken styrt tilbake til eigaren, eller apparata deler tilstand via ein leverandørmekanisme, eller designet verkar ikkje.

Difor er to sunne NVA-ar ikkje ein helsesjekk for inspeksjon. Helse handlar om nåbarheit; inspeksjon handlar om kva instans som held sesjonen.

Støtta HA-modellar og kva kvar av dei lovar

Microsoft's guidance on Virtual WAN-ruteintensjon skildrar avgrensa åtferd for dobbeltrolle-tilkopling og brannmur-NVA-ar, der direkteruting kan omgå den normale symmetriske handhevinga til huben. Les desse notata som avgrensingar på topologien du valde, ikkje som eit forbod mot aktiv-aktiv-design. Eit leverandørpar som synkroniserer tilstand, eller styrer per flyt, kan støttast. Eit par med lik kostnad som ikkje gjer nokon av delane, er ikkje støtta.

Definer så kva som skjer med eksisterande sesjonar når ein node feilar. Rutekonvergens gjenopprettar nåbarheita for nye flytar innan sekund, medan den gamle brannmurtilstanden rett og slett er borte. Ein klientattilkopling kan vere det dokumenterte resultatet, og det er ei avgjerd som blir teken før hendinga, ikkje under ho.

Kva du bør teste før du stolar på det

Test with inspection enabled and tilgangspolicyen til arbeidslasta på plass, fordi ein av dei kan skjule asymmetrien. Send ein ny autorisert flyt i begge retningar og stadfest at same apparat såg begge halvdelane. Køyr deretter vedvarande trafikk og utløys den godkjende failoveren, og sjå om etablerte sesjonar overlever eller koplar til på nytt.

Korreler kvar flyt med apparatet som handsama han. Ein pakkefangst på éin NVA fortel deg nesten ingenting viss svaret aldri kom tilbake dit.

Til slutt skriv du planen som tre separate linjer: ruteeigarskap, trafikkstyring og eigarskap til sesjonstilstand. Design bryt saman når dei to første er løyste og den tredje blir antatt.