Dues adreces VPN on-prem: dos peers d'Azure, no un

El diagrama té dos enllaços d'internet a la sucursal i una passarel·la VPN d'Azure, de manera que la passarel·la de xarxa local rep totes dues adreces públiques. Sembla ordenat i no funciona com el diagrama insinua. Cada dispositiu VPN on-prem és una relació de peer separada, i el disseny de diversos dispositius de Microsoft dona a cadascun el seu propi recurs de passarel·la de xarxa local i la seva pròpia connexió. Afegir una segona adreça a un sol recurs no crea un segon peer. Crea un recurs que no descriu correctament cap dels dos dispositius.

El mite: una passarel·la, dues adreces

Una passarel·la de xarxa local és una descripció d'un peer remot: un punt final públic i els prefixos privats que hi ha al darrere. No hi ha cap manera compatible de fer que aquest recurs signifiqui «qualsevol d'aquests dos aparells».

La mateixa confusió va en l'altra direcció, on dues IP públiques d'Azure es llegeixen com a prova que existeixen dues passarel·les d'Azure.

Compteu els objectes i després els túnels

Preneu dos dispositius on-prem gestionats de manera independent, cadascun amb la seva adreça pública i accés a les mateixes xarxes privades, més una passarel·la d'Azure basada en encaminament en mode actiu-actiu. La passarel·la d'Azure té dues instàncies actives amb IP públiques separades. Cada dispositiu on-prem es connecta a totes dues instàncies. Aquesta és la malla completa, i el recompte d'objectes se'n deriva, no del diagrama.

L'aritmètica és prou curta per enganxar-la al document de disseny:

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

Un recurs de connexió pot portar més d'un túnel subjacent, així que quatre túnels no impliquen quatre passarel·les de xarxa virtual. Dues IP públiques d'Azure tampoc no són els mateixos objectes que les dues passarel·les de xarxa local que descriuen el lloc remot.

Què afegeix l'actiu-actiu a la banda d'Azure

L'actiu-actiu converteix la passarel·la d'Azure d'una instància activa en dues, cadascuna amb la seva IP pública, i és el que fa possible una malla completa. No duplica el rendiment d'un sol flux. Tampoc no elimina la necessitat que la banda on-prem admeti multipath d'igual cost si tots dos dispositius reenvien alhora. Confirmeu el mode de la passarel·la, l'SKU i la capacitat del dispositiu remot abans de provisionar res.

Una passarel·la en espera passiva és un disseny perfectament vàlid; simplement produeix un recompte de túnels diferent.

BGP fa utilitzables tots dos camins

Per al disseny de diversos dispositius, tots dos dispositius on-prem executen BGP. Doneu a cadascun una adreça de peer BGP única i anuncieu els mateixos prefixos privats previstos pels camins rellevants. Els prefixos privats identifiquen les xarxes protegides, mentre que les adreces públiques identifiquen on acaben les connexions de transport xifrades. Confondre les dues coses produeix un disseny on tots els túnels estan actius i les rutes són incorrectes.

Planifiqueu l'encaminament de retorn i qualsevol inspecció amb estat que hagi de tolerar qualsevol dels dos camins. Una sessió IKE sana a cada punt final no demostra que una càrrega de treball pugui utilitzar cada ruta anunciada.

La selecció per flux no és agrupació d'amplada de banda

Azure selecciona un camí per flux mitjançant un hash sobre l'adreçament i els ports del flux. En estat estacionari, els paquets d'un flux TCP o UDP determinat normalment prenen el mateix túnel, i la banda on-prem pot triar un túnel diferent per a la direcció de retorn. Per tant, dos dispositius i quatre túnels milloren la disponibilitat, no la velocitat d'una transferència. Quan una diapositiva del proveïdor promet agregació, descriu una altra funció o un malentès.

Proveu amb fluxos paral·lels si voleu veure com es reparteixen els camins, i amb un sol flux si voleu veure el límit.

Quina redundància heu eliminat realment

Dues adreces WAN en un sol aparell milloren les opcions d'enllaç d'accés mentre comparteixen l'alimentació, el programari i l'estat de fallada d'aquest aparell. No són el mateix que dos dispositius, i cap configuració a la banda d'Azure ho canvia. Seguiu el disseny de doble WAN o de clúster compatible del proveïdor en lloc d'inferir redundància del nombre d'adreces. Després proveu-ho: traieu un camí alhora i confirmeu les rutes restants més un intercanvi real d'aplicació en tots dos sentits.

Espereu retards de detecció i convergència, i espereu que algunes sessions existents acabin.