Por que ponto a site exige um gateway Azure VPN baseado em rotas

Um gateway baseado em políticas constrói um túnel IPsec selecionado pelos seletores de tráfego e não tem interface para entregar as rotas dos clientes. A conexão ponto a site é uma função de roteamento: o gateway possui um pool de endereços de clientes e instala rotas para esses clientes na rede virtual. É essa divergência que explica o portal não mostrar nenhuma opção para adicioná-la. Nada no gateway existente pode ser alternado para produzir a interface, então a mudança é uma substituição e não uma edição de configuração.

A ordem importa mais do que as etapas individuais. Se a sequência estiver errada, a interrupção entre sites ultrapassa a janela de manutenção.

O que um gateway baseado em políticas realmente faz

Um gateway baseado em políticas compara os pacotes com os seletores de tráfego configurados na conexão e envia as correspondências para um único túnel. Não há interface de túnel com endereço, e nenhuma rota por cliente aparece em qualquer lugar da rede virtual. A tabela de rotas apenas recebe os prefixos locais que apontam para o gateway. Esse modelo basta para uma conexão site a site entre dois espaços de endereços fixos.

Um gateway baseado em rotas funciona ao contrário: apresenta uma interface de túnel, e as rotas decidem o que entra nela. A conexão ponto a site, e qualquer projeto cujo conjunto de pares mude, dependem da existência dessa interface.

Por que o pool de clientes precisa dessa interface

Quando um notebook se conecta, o gateway atribui a ele um endereço do pool ponto a site. A rede virtual então precisa de uma rota dizendo que esse endereço é alcançável pelo gateway. Sem uma interface de túnel não há nada a que anexar essa rota.

O pool vem de um intervalo que você determina, e o gateway aloca dele. Se esse intervalo se sobrepõe à rede local ou a uma rede virtual emparelhada, o conflito só aparece depois que um cliente se conecta, o que é um mau momento para descobri-lo. Reserve o pool antes do início da migração.

O tipo também não é uma configuração por conexão. Um gateway tem um único tipo, e cada conexão que ele mantém se comporta de acordo, então um projeto misto precisa de um segundo gateway e não de uma segunda conexão.

O tipo é fixado na criação

A Microsoft afirma que um gateway de rede virtual não pode ser alterado entre baseado em políticas e baseado em rotas após a implantação. Não existe comando de conversão nem botão no portal. Criar um segundo gateway na mesma sub-rede também não é solução alternativa, porque o Azure permite um gateway por rede virtual. A migração é, portanto, remover, reconstruir e reconectar.

Isso também inclui a decisão de SKU na mesma construção. Mudar para um SKU maior depois é outra substituição de gateway com outra interrupção.

Um gateway, uma GatewaySubnet

O gateway fica em uma sub-rede chamada GatewaySubnet, e apenas um gateway a ocupa. Dimensionar essa sub-rede faz parte da preparação, porque um SKU maior precisa de mais endereços e uma sub-rede não pode ser reduzida depois. Anote as configurações atuais de site a site, a chave compartilhada, o gateway de rede local e as rotas efetivas antes de tocar em qualquer coisa. Depois trate a janela como interrupção, porque o túnel site a site fica fora até a nova conexão ser configurada.

Uma ordem de reconstrução que mantém a interrupção limitada: crie o gateway baseado em rotas, recrie a conexão site a site para o mesmo gateway de rede local, confirme o túnel e uma requisição de host para host, e só então adicione o ponto a site e gere um novo pacote de cliente.

O que a substituição não corrige

Um segundo limite pertence ao par e não ao Azure. Um dispositivo local baseado em políticas só alcança a rede virtual à qual se conecta, e não pode transitar para outras redes locais ou outras redes virtuais pelo mesmo gateway. Substituir o lado do Azure não muda o que o par pode selecionar.

Se o requisito for realmente o trânsito entre sites, a resposta é um dispositivo par baseado em rotas ou uma topologia em que cada destino termina separadamente. Decida isso antes de prometer uma data, porque a substituição do gateway sozinha não entregará.

Ordem das operações e verificações

Verifique cada capacidade separadamente. Primeiro o estado do túnel site a site e uma requisição de host para host, depois uma conexão ponto a site e um recurso privado, depois qualquer caminho de trânsito que o projeto afirme. Um estado verde do gateway prova apenas que a associação de segurança subiu, e nada mais. Mantenha as verificações nessa ordem para que uma falha aponte a etapa que a introduziu.

Gere novamente os pacotes de cliente após qualquer mudança de topologia e mantenha o pool longe de cada intervalo local e emparelhado. As restrições e as diferenças entre SKUs estão reunidas na referência de configurações do Azure VPN Gateway.