Dvě on-prem VPN adresy: dva Azure peery, ne jeden

Diagram má v pobočce dvě internetové linky a jednu bránu VPN v Azure, takže brána místní sítě dostane obě veřejné adresy. Vypadá to uklizeně a nefunguje to tak, jak diagram naznačuje. Každé on-prem VPN zařízení je samostatný vztah s peerem a návrh Microsoftu pro více zařízení dává každému vlastní prostředek brány místní sítě a vlastní připojení. Přidání druhé adresy k jednomu prostředku nevytvoří druhý peer. Vytvoří prostředek, který správně nepopisuje ani jedno zařízení.

Mýtus: jedna brána, dvě adresy

Brána místní sítě je popis vzdáleného peeru: jeden veřejný koncový bod a privátní prefixy za ním. Neexistuje podporovaný způsob, jak tomuto prostředku dát význam „kterékoli z těchto dvou zařízení“.

Stejné zmatení jde i opačným směrem, kde se dvě veřejné IP adresy Azure čtou jako důkaz, že existují dvě brány Azure.

Spočítejte objekty, pak tunely

Vezměte dvě nezávisle provozovaná on-prem zařízení, každé s vlastní veřejnou adresou a přístupem ke stejným privátním sítím, plus jednu bránu Azure založenou na směrování v režimu aktivní-aktivní. Brána Azure má dvě aktivní instance s oddělenými veřejnými IP adresami. Každé on-prem zařízení se připojuje k oběma instancím. To je úplná síť a počet objektů z ní vyplývá, ne z diagramu.

Aritmetika je dost krátká na to, aby se vložila do návrhového dokumentu:

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

Prostředek připojení může nést více než jeden podkladový tunel, takže čtyři tunely neznamenají čtyři brány virtuální sítě. Dvě veřejné IP adresy Azure také nejsou stejné objekty jako dvě brány místní sítě, které popisují vzdálené pracoviště.

Co přidává aktivní-aktivní režim na straně Azure

Aktivní-aktivní režim mění bránu Azure z jedné aktivní instance na dvě, každou s vlastní veřejnou IP adresou, a právě on umožňuje úplnou síť. Nezdvojnásobuje propustnost jednoho toku. Neodstraňuje ani potřebu, aby on-prem strana podporovala vícesměrové směrování se stejnými náklady, pokud obě zařízení přeposílají současně. Před zřízením čehokoli potvrďte režim brány, SKU a schopnosti vzdáleného zařízení.

Brána v pasivním pohotovostním režimu je zcela platný návrh; jen dává jiný počet tunelů.

BGP zpřístupňuje obě cesty

Pro návrh s více zařízeními provozují obě on-prem zařízení BGP. Dejte každému jedinečnou adresu peeru BGP a inzerujte stejné zamýšlené privátní prefixy přes příslušné cesty. Privátní prefixy určují chráněné sítě, zatímco veřejné adresy určují, kde končí šifrovaná nosná připojení. Záměna těchto dvou věcí vede k návrhu, kde jsou všechny tunely aktivní a trasy špatné.

Naplánujte zpětné směrování a jakoukoli stavovou kontrolu, která musí snést kteroukoli cestu. Zdravá relace IKE na každém koncovém bodu nedokazuje, že pracovní zátěž může použít každou inzerovanou trasu.

Výběr podle toku není sdružování šířky pásma

Azure vybírá cestu pro každý tok pomocí hashe přes adresy a porty toku. V ustáleném stavu pakety daného toku TCP nebo UDP obvykle jdou stejným tunelem a on-prem strana může pro zpětný směr zvolit jiný tunel. Dvě zařízení a čtyři tunely tedy zlepšují dostupnost, ne rychlost jednoho přenosu. Když prodejní prezentace slibuje agregaci, popisuje jinou funkci nebo nedorozumění.

Testujte s paralelními toky, pokud chcete vidět šíření cest, a s jediným tokem, pokud chcete vidět limit.

Jakou redundanci jste vlastně odstranili

Dvě WAN adresy na jednom zařízení zlepšují možnosti přístupové linky, ale sdílejí napájení, software a poruchový stav tohoto zařízení. Nejsou totéž co dvě zařízení a žádná konfigurace na straně Azure to nezmění. Místo odvozování redundance z počtu adres postupujte podle výrobcem podporovaného návrhu se dvěma WAN nebo clusterem. Pak to otestujte: odeberte vždy jednu cestu a potvrďte zbývající trasy a skutečnou výměnu aplikace v obou směrech.

Očekávejte zpoždění detekce a konvergence a očekávejte, že některé stávající relace skončí.