Två lokala VPN-adresser: två Azure-peers, inte en

Diagrammet har två internetlänkar på filialen och en Azure VPN-gateway, så den lokala nätverksgatewayen får båda de offentliga adresserna. Det ser prydligt ut och det fungerar inte som diagrammet antyder. Varje lokal VPN-enhet är en separat peer-relation, och Microsofts design för flera enheter ger var och en sin egen lokala nätverksgateway-resurs och sin egen anslutning. Att lägga till en andra adress på en enda resurs skapar inte en andra peer. Det skapar en resurs som inte beskriver någon av enheterna korrekt.

Myten: en gateway, två adresser

En lokal nätverksgateway är en beskrivning av en fjärr-peer: en offentlig slutpunkt och de privata prefixen bakom den. Det finns inget stödt sätt att få den resursen att betyda »endera av dessa två enheter«.

Samma förvirring finns i den andra riktningen, där två offentliga Azure-IP:er läses som bevis på att det finns två Azure-gatewayer.

Räkna objekten, räkna sedan tunnlarna

Ta två oberoende drivna lokala enheter, var och en med sin egen offentliga adress och åtkomst till samma privata nätverk, plus en ruttbaserad Azure-gateway i aktiv-aktiv-läge. Azure-gatewayen har två aktiva instanser med separata offentliga IP:er. Varje lokal enhet ansluter till båda instanserna. Det är det fullständiga nätet, och antalet objekt följer av det, inte av diagrammet.

Aritmetiken är kort nog att klistra in i designdokumentet:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

En anslutningsresurs kan bära mer än en underliggande tunnel, så fyra tunnlar innebär inte fyra virtuella nätverksgatewayer. Två offentliga Azure-IP:er är inte heller samma objekt som de två lokala nätverksgatewayer som beskriver fjärrplatsen.

Vad aktiv-aktiv tillför på Azure-sidan

Aktiv-aktiv ändrar Azure-gatewayen från en aktiv instans till två, var och en med sin egen offentliga IP, och det är detta som över huvud taget gör ett fullständigt nät möjligt. Det fördubblar inte genomströmningen för ett enda flöde. Det tar inte heller bort behovet av att den lokala sidan stöder multipath med lika kostnad om båda enheterna vidarebefordrar samtidigt. Bekräfta gatewayläge, SKU och fjärrenhetens förmåga innan du etablerar något.

En gateway i passivt standby är en helt giltig design; den ger bara ett annat antal tunnlar.

BGP gör båda vägarna användbara

För designen med flera enheter kör båda lokala enheterna BGP. Ge var och en en unik BGP-peer-adress och annonsera samma avsedda privata prefix över de relevanta vägarna. De privata prefixen identifierar de skyddade näten, medan de offentliga adresserna identifierar var de krypterade bäraranslutningarna slutar. Att blanda ihop de två ger en design där varje tunnel är uppe och rutterna är fel.

Planera returroutning och all tillståndsbaserad inspektion som måste tåla endera av de två vägarna. En frisk IKE-session på varje slutpunkt bevisar inte att en arbetsbelastning kan använda varje annonserad rutt.

Flödesbaserat val är inte bandbreddspoolning

Azure väljer en väg per flöde med hjälp av en hash över flödets adressering och portar. I stabilt tillstånd tar paket i ett givet TCP- eller UDP-flöde normalt samma tunnel, och den lokala sidan kan välja en annan tunnel för returriktningen. Därför förbättrar två enheter och fyra tunnlar tillgängligheten, inte hastigheten för en överföring. När en leverantörsbild lovar aggregering beskriver den en annan funktion eller ett missförstånd.

Testa med parallella flöden om du vill se vägarna sprida sig, och med ett enda flöde om du vill se gränsen.

Vilken redundans du faktiskt tog bort

Två WAN-adresser på en enda enhet förbättrar alternativen för åtkomstlänken men delar enhetens ström, programvara och feltillstånd. De är inte samma sak som två enheter, och ingen Azure-sidig konfiguration ändrar det. Följ leverantörens stödda design med dubbla WAN eller kluster i stället för att härleda redundans från antalet adresser. Testa det sedan: ta bort en väg i taget och bekräfta de återstående rutterna plus ett verkligt applikationsutbyte i båda riktningarna.

Förvänta dig fördröjningar i identifiering och konvergens, och förvänta dig att vissa befintliga sessioner avslutas.