Por que o punto a sitio necesita unha pasarela Azure VPN baseada en rutas

Unha pasarela baseada en políticas constrúe un túnel IPsec seleccionado polos selectores de tráfico e non ten interface á que entregar as rutas dos clientes. A conexión de punto a sitio é unha función de enrutamento: a pasarela posúe un conxunto de enderezos de cliente e instala rutas cara a eses clientes na rede virtual. Esa discrepancia é a razón pola que o portal non mostra ningunha opción para engadila. Nada na pasarela existente se pode alternar para producir a interface, así que o cambio é unha substitución e non unha edición da configuración.

A orde importa máis que os pasos individuais. Se te equivocas na secuencia, a interrupción de sitio a sitio esténdese máis alá da xanela de mantemento.

Que fai realmente unha pasarela baseada en políticas

Unha pasarela baseada en políticas compara os paquetes cos selectores de tráfico configurados na conexión e envía as coincidencias a un só túnel. Non hai ningunha interface de túnel con enderezo, e non aparece ningunha ruta por cliente en ningún lugar da rede virtual. A táboa de rutas simplemente recibe os prefixos locais que apuntan á pasarela. Ese modelo abonda para unha conexión de sitio a sitio entre dous espazos de enderezos fixos.

Unha pasarela baseada en rutas funciona ao revés: presenta unha interface de túnel e as rutas deciden que entra nela. A conexión de punto a sitio, e calquera deseño cuxo conxunto de pares cambia, dependen de que esa interface exista.

Por que o conxunto de clientes necesita esa interface

Cando un portátil se conecta, a pasarela asígnalle un enderezo do conxunto de punto a sitio. A rede virtual necesita entón unha ruta que diga que ese enderezo é accesible a través da pasarela. Sen unha interface de túnel non hai nada a que ligar esa ruta.

O conxunto procede dun intervalo que ti designas, e a pasarela asigna del. Se ese intervalo se solapa coa rede local ou cunha rede virtual emparellada, o conflito só aparece despois de que se conecte un cliente, que é un mal momento para descubrilo. Reserva o conxunto antes de que comece a migración.

O tipo tampouco é unha configuración por conexión. Unha pasarela ten un só tipo, e cada conexión que mantén compórtase en consecuencia, así que un deseño mixto necesita unha segunda pasarela e non unha segunda conexión.

O tipo queda fixado na creación

Microsoft afirma que unha pasarela de rede virtual non se pode cambiar entre baseada en políticas e baseada en rutas despois do despregamento. Non hai comando de conversión nin interruptor no portal. Crear unha segunda pasarela na mesma subrede tampouco é unha solución alternativa, porque Azure permite unha pasarela por rede virtual. Por tanto, a migración consiste en eliminar, reconstruír e volver conectar.

Iso tamén integra a decisión de SKU na mesma construción. Pasar a un SKU maior máis adiante é outra substitución de pasarela con outra interrupción.

Unha pasarela, unha GatewaySubnet

A pasarela vive nunha subrede chamada GatewaySubnet, e só unha pasarela a ocupa. Dimensionar esa subrede forma parte da preparación, porque un SKU maior necesita máis enderezos e unha subrede non se pode reducir despois. Anota a configuración actual de sitio a sitio, a clave compartida, a pasarela de rede local e as rutas efectivas antes de tocar nada. Despois trata a xanela como unha interrupción, porque o túnel de sitio a sitio permanece caído ata que se configura a nova conexión.

Unha orde de reconstrución que mantén a interrupción acoutada: crea a pasarela baseada en rutas, volve crear a conexión de sitio a sitio cara á mesma pasarela de rede local, confirma o túnel e unha solicitude de host a host, e só entón engade punto a sitio e xera un paquete de cliente novo.

Que non arranxa a substitución

Un segundo límite pertence ao par e non a Azure. Un dispositivo local baseado en políticas só pode alcanzar a rede virtual á que se conecta, e non pode transitar cara a outras redes locais nin outras redes virtuais a través da mesma pasarela. Substituír o lado de Azure non cambia o que o par pode seleccionar.

Se o requisito é realmente tránsito entre sitios, a resposta é un dispositivo par baseado en rutas ou unha topoloxía na que cada destino termina por separado. Decide iso antes de prometer unha data, porque a substitución da pasarela por si soa non o entregará.

Orde das operacións e das comprobacións

Verifica cada capacidade por separado. Primeiro o estado do túnel de sitio a sitio e unha solicitude de host a host, despois unha conexión de punto a sitio e un recurso privado, despois calquera camiño de tránsito que afirme o deseño. Un estado verde da pasarela só demostra que a asociación de seguridade se levantou, e nada máis. Mantén as comprobacións nesa orde para que un fallo sinale a etapa que o introduciu.

Xera de novo os paquetes de cliente tras calquera cambio de topoloxía e mantén o conxunto lonxe de cada intervalo local e emparellado. As restricións e as diferenzas entre SKU recóllense na referencia de configuración de Azure VPN Gateway.