Azure NVA-inspektion: varför svaret går genom en annan brandvägg

Ett flöde från filialen till Azure kan routas korrekt i båda riktningarna och ändå misslyckas, eftersom de två riktningarna tar olika enheter. Begäran lämnar filialen över VPN, landar på NVA A och når arbetsbelastningen. Svaret lämnar arbetsbelastningen, matchar en rutt som pekar på NVA B och dör där. Varje rutt i den bilden är giltig, och TCP-sessionen är fortfarande bruten.

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

Det gapet är hela ämnet här: routningskonvergens och ägarskap av sessionstillstånd är olika problem som ser identiska ut i ett diagram.

Vad Route Server faktiskt programmerar

Azure Route Server peerar med BGP-talare som stöds, lär sig deras rutter och programmerar dem i det virtuella nätverkets effektiva rutter. Det är ett kontrollplansarbete. Den läser inte en leverantörsbrandväggs sessionstabell och vet inte vilken enhet som släppte igenom en given anslutning. Två nästa hopp med lika kostnad är, för detta tyg, helt enkelt två sätt att nå samma prefix, och den kommer att använda endera.

Att lära sig en rutt bevisar därför nåbarhet. Det bevisar ingenting om huruvida enheten i andra änden har sett detta flöde tidigare.

Läs båda riktningarna innan du designar

Börja med att skriva ned den styrning du faktiskt har i varje riktning, inte den du avsåg. Mer specifika BGP-rutter, användardefinierade rutter och gatewaybeteende konkurrerar alla, och vinnaren avgörs per destination, inte per session. En standardrutt på NVA betyder inte att varje privat prefix går genom den.

En användbar kontroll är att fråga, för en specifik arbetsbelastnings-IP, vilket nästa hopp varje riktning löses till. Om svaret är två olika enheter har du ett asymmetriproblem, oavsett om det har visat sig eller inte.

Var tillståndet bor

En stateful brandvägg släpper igenom en anslutning och håller en tabellpost med nyckel på fem-tupeln. Svaret måste nå enheten som håller posten, eller så måste enheten skaffa tillståndet på annat sätt. Ingenting i Azures dataplan vidarebefordrar posten mellan enheter. Antingen styrs trafiken tillbaka till ägaren, eller så delar enheterna tillstånd via en leverantörsmekanism, eller så fungerar inte designen.

Det är därför två friska NVA:er inte är en hälsokontroll för inspektion. Hälsa handlar om nåbarhet; inspektion handlar om vilken instans som håller sessionen.

HA-modeller som stöds och vad var och en lovar

Microsoft's guidance on Virtual WAN-routningsavsikt beskriver begränsat beteende för dubbelrollsanslutning och brandväggs-NVA:er, där direkt routning kan kringgå hubbens normala symmetriska tillämpning. Läs dessa anteckningar som begränsningar för den valda topologin, inte som ett förbud mot aktiv-aktiv-design. Ett leverantörspar som synkroniserar tillstånd, eller styr per flöde, kan stödjas. Ett par med lika kostnad som inte gör något av det, stöds inte.

Definiera sedan vad som händer med befintliga sessioner när en nod misslyckas. Routningskonvergens återställer nåbarheten för nya flöden inom sekunder, medan det gamla brandväggstillståndet helt enkelt är borta. En klientåteranslutning kan vara det dokumenterade resultatet, och det är ett beslut som fattas före incidenten, inte under den.

Vad du bör testa innan du litar på det

Test with inspection enabled and arbetsbelastningens åtkomstpolicy på plats, eftersom endera kan dölja asymmetrin. Skicka ett nytt auktoriserat flöde i båda riktningarna och bekräfta att samma enhet såg båda halvorna. Kör sedan varaktig trafik och utlös den godkända failovern, och se om etablerade sessioner överlever eller återansluter.

Korrelera varje flöde med den enhet som hanterade det. En paketinsamling på en NVA säger dig nästan ingenting om svaret aldrig kom tillbaka dit.

Skriv till sist planen som tre separata rader: ruttägarskap, trafikstyrning och ägarskap av sessionstillstånd. Designer går sönder när de två första är lösta och den tredje antas.