Dous enderezos VPN locais: dous pares de Azure, non un

O diagrama ten dúas ligazóns de internet na sucursal e unha pasarela VPN de Azure, así que a pasarela de rede local recibe ambos os enderezos públicos. Parece ordenado e non funciona como o diagrama implica. Cada dispositivo VPN local é unha relación de par independente, e o deseño de varios dispositivos de Microsoft dá a cada un o seu propio recurso de pasarela de rede local e a súa propia conexión. Engadir un segundo enderezo a un único recurso non crea un segundo par. Crea un recurso que non describe correctamente ningún dos dous dispositivos.

O mito: unha pasarela, dous enderezos

Unha pasarela de rede local é a descrición dun par remoto: un extremo público e os prefixos privados que hai detrás. Non hai forma compatible de facer que ese recurso signifique «calquera destes dous aparellos».

A mesma confusión vai na outra dirección, onde dous IP públicas de Azure se len como proba de que existen dúas pasarelas de Azure.

Conte os obxectos e despois os túneles

Tome dous dispositivos locais operados de forma independente, cada un co seu propio enderezo público e acceso ás mesmas redes privadas, máis unha pasarela de Azure baseada en rutas en modo activo-activo. A pasarela de Azure ten dúas instancias activas con IP públicas separadas. Cada dispositivo local conéctase a ambas as instancias. Esa é a malla completa, e o reconto de obxectos derívase dela, non do diagrama.

A aritmética é o suficientemente curta para pegala no documento de deseño:

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

Un recurso de conexión pode transportar máis dun túnel subxacente, así que catro túneles non implican catro pasarelas de rede virtual. Dous IP públicas de Azure tampouco son os mesmos obxectos que as dúas pasarelas de rede local que describen o sitio remoto.

Que engade o activo-activo no lado de Azure

O activo-activo cambia a pasarela de Azure dunha instancia activa a dúas, cada unha coa súa propia IP pública, e é o que fai posible unha malla completa. Non duplica o rendemento dun só fluxo. Tampouco elimina a necesidade de que o lado local admita multipath de igual custo se ambos os dispositivos reenvían á vez. Confirme o modo da pasarela, a SKU e a capacidade do dispositivo remoto antes de aprovisionar nada.

Unha pasarela en espera pasiva é un deseño perfectamente válido; simplemente produce un reconto de túneles distinto.

BGP fai utilizables ambos os camiños

Para o deseño de varios dispositivos, ambos os dispositivos locais executan BGP. Dea a cada un un enderezo de par BGP único e anuncie os mesmos prefixos privados previstos polos camiños relevantes. Os prefixos privados identifican as redes protexidas, mentres que os enderezos públicos identifican onde rematan as conexións de transporte cifradas. Confundir ambos produce un deseño no que todos os túneles están activos e as rutas son incorrectas.

Planifique o encamiñamento de retorno e calquera inspección con estado que deba tolerar calquera dos dous camiños. Unha sesión IKE sa en cada extremo non demostra que unha carga de traballo poida usar cada ruta anunciada.

A selección por fluxo non é agregación de ancho de banda

Azure selecciona un camiño por fluxo mediante un hash sobre o enderezo e os portos do fluxo. En estado estacionario, os paquetes dun fluxo TCP ou UDP determinado adoitan tomar o mesmo túnel, e o lado local pode escoller outro túnel para a dirección de retorno. Por tanto, dous dispositivos e catro túneles melloran a dispoñibilidade, non a velocidade dunha transferencia. Cando unha diapositiva do provedor promete agregación, describe outra función ou un malentendido.

Probe con fluxos paralelos se quere ver como se reparten os camiños, e cun só fluxo se quere ver o límite.

Que redundancia eliminou realmente

Dous enderezos WAN nun só dispositivo melloran as opcións de ligazón de acceso mentres comparten a alimentación, o software e o estado de fallo dese dispositivo. Non son o mesmo que dous dispositivos, e ningunha configuración do lado de Azure o cambia. Siga o deseño de dobre WAN ou de clúster compatible do provedor en lugar de inferir redundancia do número de enderezos. Logo probeo: retire un camiño cada vez e confirme as rutas restantes máis un intercambio real de aplicación en ambos os sentidos.

Espere atrasos de detección e converxencia, e espere que algunhas sesións existentes rematen.