To on-prem VPN-adresser: to Azure-peers, ikke én

Diagrammet har to internetforbindelser på filialen og én Azure VPN-gateway, så den lokale netværksgateway får begge offentlige adresser. Det ser pænt ud, og det virker ikke, som diagrammet antyder. Hver on-prem VPN-enhed er et separat peer-forhold, og Microsofts design til flere enheder giver hver enhed sin egen lokale netværksgateway-ressource og sin egen forbindelse. At tilføje en anden adresse til én ressource skaber ikke en anden peer. Det skaber en ressource, der ikke beskriver nogen af enhederne korrekt.

Myten: én gateway, to adresser

En lokal netværksgateway er en beskrivelse af en fjern peer: ét offentligt endepunkt og de private præfikser bag det. Der findes ingen understøttet måde at få den ressource til at betyde »en af disse to enheder«.

Den samme forvirring findes i den anden retning, hvor to offentlige Azure-IP'er læses som bevis på, at der findes to Azure-gateways.

Tæl objekterne, og tæl derefter tunnelerne

Tag to uafhængigt drevne on-prem-enheder, hver med sin egen offentlige adresse og adgang til de samme private netværk, plus én rutebaseret Azure-gateway i aktiv-aktiv tilstand. Azure-gatewayen har to aktive instanser med separate offentlige IP'er. Hver on-prem-enhed opretter forbindelse til begge instanser. Det er det fulde mesh, og antallet af objekter følger af det, ikke af diagrammet.

Regnestykket er kort nok til at indsætte 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 forbindelsesressource kan bære mere end én underliggende tunnel, så fire tunneler betyder ikke fire virtuelle netværksgateways. To offentlige Azure-IP'er er heller ikke de samme objekter som de to lokale netværksgateways, der beskriver det eksterne site.

Hvad aktiv-aktiv tilføjer på Azure-siden

Aktiv-aktiv ændrer Azure-gatewayen fra én aktiv instans til to, hver med sin egen offentlige IP, og det er det, der overhovedet gør et fuldt mesh muligt. Det fordobler ikke gennemstrømningen af en enkelt flow. Det fjerner heller ikke behovet for, at on-prem-siden understøtter multipath med lige omkostninger, hvis begge enheder videresender samtidig. Bekræft gatewaytilstand, SKU og fjernenhedens formåen, før der klargøres noget.

En gateway i passiv standby er et helt gyldigt design; den giver blot et andet antal tunneler.

BGP gør begge veje brugbare

Til designet med flere enheder kører begge on-prem-enheder BGP. Giv hver en unik BGP-peer-adresse, og annoncer de samme tilsigtede private præfikser over de relevante veje. De private præfikser identificerer de beskyttede netværk, mens de offentlige adresser identificerer, hvor de krypterede bærerforbindelser slutter. At forveksle de to giver et design, hvor hver tunnel er oppe, og ruterne er forkerte.

Planlæg returrouting og enhver stateful inspektion, der skal tolerere hver af de to veje. En sund IKE-session på hvert endepunkt beviser ikke, at en arbejdsbyrde kan bruge hver annonceret rute.

Flowbaseret valg er ikke båndbreddepulje

Azure vælger en vej for hver flow ved hjælp af en hash over flowets adressering og porte. I stabil tilstand tager pakker i en given TCP- eller UDP-flow normalt den samme tunnel, og on-prem-siden kan vælge en anden tunnel til returretningen. To enheder og fire tunneler forbedrer derfor tilgængeligheden, ikke hastigheden af en overførsel. Når en leverandørslide lover aggregering, beskriver den en anden funktion eller en misforståelse.

Test med parallelle flows, hvis du vil se vejene sprede sig, og med en enkelt flow, hvis du vil se grænsen.

Hvilken redundans du faktisk fjernede

To WAN-adresser på én enhed forbedrer mulighederne for adgangslinjen, men deler enhedens strøm, software og fejltilstand. De er ikke det samme som to enheder, og ingen mængde Azure-side-konfiguration ændrer det. Følg leverandørens understøttede design med dobbelt WAN eller klynge i stedet for at udlede redundans af antallet af adresser. Test det derefter: fjern én vej ad gangen, og bekræft de resterende ruter plus en rigtig applikationsudveksling i begge retninger.

Forvent forsinkelser i registrering og konvergens, og forvent, at nogle eksisterende sessioner slutter.