Twee on-prem-VPN-adresse: twee Azure-peers, nie een nie

Die diagram het twee internetverbindings by die tak en een Azure VPN-gateway, dus kry die plaaslike netwerkgateway albei publieke adresse. Dit lyk netjies, en dit werk nie soos die diagram impliseer nie. Elke on-prem-VPN-toestel is ’n aparte peer-verhouding, en Microsoft se ontwerp vir veelvuldige toestelle gee elkeen sy eie plaaslike netwerkgateway-hulpbron en sy eie verbinding. Om ’n tweede adres by ’n enkele hulpbron te voeg, skep nie ’n tweede peer nie. Dit skep ’n hulpbron wat nie een van die toestelle behoorlik beskryf nie.

Die mite: een gateway, twee adresse

’n Plaaslike netwerkgateway is ’n beskrywing van ’n afgeleë peer: een publieke eindpunt en die private voorvoegsels daarby. Daar is geen ondersteunde manier om daardie hulpbron “enige van hierdie twee toestelle” te laat beteken nie.

Dieselfde verwarring loop in die ander rigting, waar twee Azure-publieke IP’s gelees word as bewys dat twee Azure-gateways bestaan.

Tel die objekte, dan die tonnels

Neem twee onafhanklik bedryfde on-prem-toestelle, elk met sy eie publieke adres en toegang tot dieselfde private netwerke, plus een op roete gebaseerde Azure-gateway in aktief-aktiewe modus. Die Azure-gateway het twee aktiewe instansies met afsonderlike publieke IP’s. Elke on-prem-toestel verbind met albei instansies. Dit is die volledige maas, en die objekte volg daaruit, nie uit die diagram nie.

Die rekenkunde is kort genoeg om in die ontwerpdokument te plak:

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

’n Verbindingshulpbron kan meer as een onderliggende tonnel dra, so vier tonnels impliseer nie vier virtuele netwerkgateways nie. Twee Azure-publieke IP’s is ook nie dieselfde objekte as die twee plaaslike netwerkgateways wat die afgeleë terrein beskryf nie.

Wat aktief-aktief aan die Azure-kant byvoeg

Aktief-aktief verander die Azure-gateway van een aktiewe instansie na twee, elk met sy eie publieke IP, en dit is wat ’n volledige maas hoegenaamd moontlik maak. Dit verdubbel nie die deurset van ’n enkele vloei nie. Dit verwyder ook nie die vereiste dat die on-prem-kant gelyke-koste multipad moet ondersteun as albei toestelle gelyktydig stuur nie. Bevestig die gateway-modus, SKU en die vermoë van die afgeleë toestel voordat iets ingerig word.

’n Passief-reserwe-gateway is ’n heeltemal geldige ontwerp; dit lewer bloot ’n ander tonneltelling.

BGP maak albei paaie bruikbaar

Vir die ontwerp met veelvuldige toestelle loop albei on-prem-toestelle BGP. Gee elkeen ’n unieke BGP-peeradres en adverteer dieselfde beoogde private voorvoegsels oor die relevante paaie. Die private voorvoegsels identifiseer die beskermde netwerke, terwyl die publieke adresse identifiseer waar die geënkripteerde draerverbindings eindig. Om dié twee te verwar lewer ’n ontwerp waarin elke tonnel op is en die roetes verkeerd is.

Beplan terugroetering en enige toestandbewuste inspeksie wat enige van die twee paaie moet verdra. ’n Gesonde IKE-sessie op elke eindpunt bewys nie dat ’n werklading elke geadverteerde roete kan gebruik nie.

Vloeigebaseerde keuse is nie bandwydtepoeling nie

Azure kies ’n pad per vloei met behulp van ’n hash oor die vloei se adressering en poorte. In ’n bestendige toestand neem pakkette vir ’n gegewe TCP- of UDP-vloei gewoonlik dieselfde tonnel, en die on-prem-kant kan ’n ander tonnel vir die terugrigting kies. Twee toestelle en vier tonnels verbeter dus beskikbaarheid, nie die spoed van een oordrag nie. Wanneer ’n verskaffer-skyfie samevoeging belowe, beskryf dit ’n ander funksie of ’n misverstand.

Toets met parallelle vloei as jy wil sien hoe die paaie versprei, en met ’n enkele vloei as jy die perk wil sien.

Watter oortolligheid jy werklik verwyder het

Twee WAN-adresse op een toestel verbeter toegangsverbinding-opsies terwyl dit daardie toestel se krag, sagteware en fouttoestand deel. Hulle is nie dieselfde as twee toestelle nie, en geen hoeveelheid Azure-kant-konfigurasie verander dit nie. Volg eerder die verskaffer se ondersteunde dubbele-WAN- of cluster-ontwerp as om oortolligheid uit die adrestelling af te lei. Toets dit dan: verwyder een pad op ’n slag en bevestig die oorblywende roetes plus ’n werklike toepassingswisseling in albei rigtings.

Verwag opsporings- en konvergensievertragings, en verwag dat sommige bestaande sessies sal eindig.