Twee on-prem VPN-adressen: twee Azure-peers, niet één

Het diagram heeft twee internetverbindingen op de vestiging en één Azure VPN-gateway, dus de lokale netwerkgateway krijgt beide openbare adressen. Het ziet er netjes uit, en het werkt niet zoals het diagram suggereert. Elk on-prem VPN-apparaat is een aparte peer-relatie, en het ontwerp voor meerdere apparaten van Microsoft geeft elk zijn eigen lokale netwerkgateway-resource en zijn eigen verbinding. Een tweede adres aan één resource toevoegen maakt geen tweede peer. Het maakt een resource die geen van beide apparaten goed beschrijft.

De mythe: één gateway, twee adressen

Een lokale netwerkgateway is een beschrijving van een externe peer: één openbaar eindpunt en de privé-prefixen erachter. Er is geen ondersteunde manier om die resource «een van deze twee apparaten» te laten betekenen.

Dezelfde verwarring bestaat in de andere richting, waar twee openbare Azure-IP's worden gelezen als bewijs dat er twee Azure-gateways bestaan.

Tel de objecten, dan de tunnels

Neem twee onafhankelijk beheerde on-prem-apparaten, elk met een eigen openbaar adres en toegang tot dezelfde privénetwerken, plus één op routes gebaseerde Azure-gateway in actief-actiefmodus. De Azure-gateway heeft twee actieve instanties met afzonderlijke openbare IP's. Elk on-prem-apparaat verbindt met beide instanties. Dat is het volledige mesh, en het aantal objecten volgt daaruit, niet uit het diagram.

De rekensom is kort genoeg om in het ontwerpdocument te plakken:

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

Eén verbindingsresource kan meer dan één onderliggende tunnel dragen, dus vier tunnels betekenen niet vier virtuele netwerkgateways. Twee openbare Azure-IP's zijn ook niet dezelfde objecten als de twee lokale netwerkgateways die de externe locatie beschrijven.

Wat actief-actief aan de Azure-kant toevoegt

Actief-actief verandert de Azure-gateway van één actieve instantie in twee, elk met een eigen openbaar IP, en dat is wat een volledig mesh überhaupt mogelijk maakt. Het verdubbelt niet de doorvoer van één flow. Het neemt ook niet de noodzaak weg dat de on-prem-kant multipath met gelijke kosten ondersteunt als beide apparaten tegelijk doorsturen. Bevestig de gatewaymodus, de SKU en de mogelijkheden van het externe apparaat voordat u iets inricht.

Een gateway in passieve standby is een volkomen geldig ontwerp; het levert alleen een ander aantal tunnels op.

BGP maakt beide paden bruikbaar

Voor het ontwerp met meerdere apparaten draaien beide on-prem-apparaten BGP. Geef elk een uniek BGP-peeradres en adverteer dezelfde beoogde privé-prefixen over de relevante paden. De privé-prefixen identificeren de beschermde netwerken, terwijl de openbare adressen identificeren waar de versleutelde transportverbindingen eindigen. De twee verwarren levert een ontwerp op waarin elke tunnel actief is en de routes onjuist zijn.

Plan de retourroutering en elke stateful inspectie die elk van beide paden moet tolereren. Een gezonde IKE-sessie op elk eindpunt bewijst niet dat een workload elke geadverteerde route kan gebruiken.

Op flows gebaseerde selectie is geen bandbreedtebundeling

Azure selecteert per flow een pad met behulp van een hash over de adressering en poorten van de flow. In stabiele toestand nemen pakketten van een bepaalde TCP- of UDP-flow normaal gesproken dezelfde tunnel, en de on-prem-kant kan voor de retourrichting een andere tunnel kiezen. Twee apparaten en vier tunnels verbeteren dus de beschikbaarheid, niet de snelheid van één overdracht. Wanneer een leveranciersdia aggregatie belooft, beschrijft die een andere functie of een misverstand.

Test met parallelle flows als u de paden wilt zien spreiden, en met één flow als u de limiet wilt zien.

Welke redundantie u daadwerkelijk hebt verwijderd

Twee WAN-adressen op één apparaat verbeteren de opties voor de toegangsverbinding, maar delen de voeding, software en foutstatus van dat apparaat. Ze zijn niet hetzelfde als twee apparaten, en geen enkele configuratie aan de Azure-kant verandert dat. Volg het door de leverancier ondersteunde dual-WAN- of clusterontwerp in plaats van redundantie af te leiden uit het aantal adressen. Test het daarna: verwijder één pad tegelijk en bevestig de resterende routes plus een echte applicatie-uitwisseling in beide richtingen.

Verwacht vertragingen bij detectie en convergentie, en verwacht dat sommige bestaande sessies eindigen.