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

Diagrammet har to internettkoblinger på filialen og én Azure VPN-gateway, så den lokale nettverksgatewayen får begge de offentlige adressene. Det ser ryddig ut, og det fungerer ikke slik diagrammet antyder. Hver lokal VPN-enhet er et eget peer-forhold, og Microsofts design for flere enheter gir hver enhet sin egen lokale nettverksgateway-ressurs og sin egen tilkobling. Å legge til en andre adresse på én ressurs skaper ikke en andre peer. Det skaper en ressurs som ikke beskriver noen av enhetene riktig.

Myten: én gateway, to adresser

En lokal nettverksgateway er en beskrivelse av en ekstern peer: ett offentlig endepunkt og de private prefiksene bak det. Det finnes ingen støttet måte å få den ressursen til å bety «en av disse to enhetene».

Den samme forvirringen finnes i den andre retningen, der to offentlige Azure-IP-er leses som bevis på at det finnes to Azure-gatewayer.

Tell objektene, og tell deretter tunnelene

Ta to uavhengig drevne lokale enheter, hver med sin egen offentlige adresse og tilgang til de samme private nettverkene, pluss én rutebasert Azure-gateway i aktiv-aktiv-modus. Azure-gatewayen har to aktive instanser med separate offentlige IP-er. Hver lokal enhet kobler til begge instansene. Det er det fulle nettet, og antallet objekter følger av det, ikke av diagrammet.

Regnestykket er kort nok til å lime inn 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 tilkoblingsressurs kan bære mer enn én underliggende tunnel, så fire tunneler betyr ikke fire virtuelle nettverksgatewayer. To offentlige Azure-IP-er er heller ikke de samme objektene som de to lokale nettverksgatewayene som beskriver det eksterne området.

Hva aktiv-aktiv tilfører på Azure-siden

Aktiv-aktiv endrer Azure-gatewayen fra én aktiv instans til to, hver med sin egen offentlige IP, og det er dette som overhodet gjør et fullt nett mulig. Det dobler ikke gjennomstrømningen til en enkelt flyt. Det fjerner heller ikke behovet for at den lokale siden støtter multipath med lik kostnad hvis begge enhetene videresender samtidig. Bekreft gatewaymodus, SKU og den eksterne enhetens evner før du klargjør noe.

En gateway i passiv standby er et helt gyldig design; den gir bare et annet antall tunneler.

BGP gjør begge veiene brukbare

For designet med flere enheter kjører begge lokale enheter BGP. Gi hver en unik BGP-peer-adresse og annonser de samme tiltenkte private prefiksene over de relevante veiene. De private prefiksene identifiserer de beskyttede nettverkene, mens de offentlige adressene identifiserer hvor de krypterte bærerforbindelsene slutter. Å forveksle de to gir et design der hver tunnel er oppe og rutene er feil.

Planlegg returruting og enhver tilstandsbasert inspeksjon som må tåle hver av de to veiene. En sunn IKE-økt på hvert endepunkt beviser ikke at en arbeidsbelastning kan bruke hver annonsert rute.

Flytbasert valg er ikke båndbreddepooling

Azure velger en vei per flyt ved hjelp av en hash over flytens adressering og porter. I stabil tilstand tar pakker i en gitt TCP- eller UDP-flyt vanligvis samme tunnel, og den lokale siden kan velge en annen tunnel for returretningen. To enheter og fire tunneler forbedrer derfor tilgjengeligheten, ikke hastigheten til én overføring. Når en leverandørslysbilde lover aggregering, beskriver det en annen funksjon eller en misforståelse.

Test med parallelle flyter hvis du vil se veiene spre seg, og med én flyt hvis du vil se grensen.

Hvilken redundans du faktisk fjernet

To WAN-adresser på én enhet forbedrer alternativene for tilgangslinjen, men deler strøm, programvare og feiltilstand for den enheten. De er ikke det samme som to enheter, og ingen Azure-side-konfigurasjon endrer det. Følg leverandørens støttede design med dobbel WAN eller klynge i stedet for å utlede redundans fra antallet adresser. Test det deretter: fjern én vei om gangen og bekreft de gjenværende rutene pluss en reell applikasjonsutveksling i begge retninger.

Forvent forsinkelser i oppdagelse og konvergens, og forvent at noen eksisterende økter avsluttes.