RRAS numa VM do Azure não é suportado: verifique antes do projeto

Abre o portal, implementa o Windows Server 2022 numa sub-rede e a função Remote Access instala-se sem problemas. Essa sequência prova que o instalador funciona, não que a Microsoft suporta a configuração. As diretrizes publicadas de suporte de software de servidor para máquinas virtuais do Azure incluem o RRAS entre as funcionalidades do Windows Server que não são suportadas em VMs do Azure, e isso é uma decisão de arquitetura, não um detalhe de resolução de problemas. Um túnel que sobe não move a implementação para dentro do limite de suporte.

O percurso abaixo começa na página de suporte e depois avança para os requisitos e as opções de substituição.

Comece na página de suporte, não no laboratório

Leia as diretrizes de suporte de VMs do Azure antes de dimensionar seja o que for. Separam produtos, funções e funcionalidades suportados em vez de tratar o Windows Server como um bloco indiferenciado. Repare em que linha cai realmente a carga de trabalho prevista, porque dois componentes que na consola parecem relacionados podem estar em linhas diferentes.

Escreva a citação no documento de projeto enquanto a página está aberta. O estado de suporte é um facto com uma fonte, e uma revisão de projeto que não o possa citar será derrubada por quem tem a demonstração.

Separe o suporte do sistema operativo do suporte de funções e funcionalidades

As mesmas diretrizes incluem o Network Policy and Access Services entre as funções suportadas, ao mesmo tempo que listam o RRAS separadamente como não suportado. Essas duas entradas descrevem coisas diferentes, e fundi-las em «o acesso remoto é suportado» é como um projeto é aprovado com base numa leitura errada. O sistema operativo ser suportado não diz nada sobre uma funcionalidade que tem a sua própria linha.

A limitação também é mais estreita do que por vezes se cita. Diz respeito a essa funcionalidade a correr dentro de uma VM do Azure; não significa que uma rede privada não possa ligar-se ao Azure, nem diz que o RRAS não é suportado em todo o lado. Um laboratório antigo que encaminha pacotes corretamente é prova sobre pacotes, não sobre a declaração de suporte.

Mantenha essas duas perguntas separadas durante o resto do projeto: funciona, e é suportado. Vai precisar de respostas diferentes e, por vezes, de responsáveis diferentes para cada uma.

Escreva o que o projeto tem de fazer realmente

Antes de escolher uma substituição, transforme a lista de locais em requisitos pelos quais um produto possa ser medido:

• Os protocolos de túnel que os equipamentos das filiais já falam, e se algum local precisa de encaminhamento dinâmico.
• Os prefixos remotos, incluindo qualquer espaço de endereços sobreposto que exija tradução em vez de encaminhamento.
• A troca de rotas com o Azure, e quem é dono de cada entrada da tabela de rotas.
• O débito e o número de ligações que a hora mais carregada tem de suportar.
• O comportamento de failover acordado pelos donos dos locais, não apenas aquele que consegue construir.

O NAT é o item que é saltado e depois decide todo o projeto. Um equipamento capaz de estabelecer IPsec pode ainda traduzir endereços de forma diferente da implementação de RRAS que substitui, e isso muda o que a filial vê como endereços de origem e o que os seus registos guardam.

Leve a lista aos responsáveis da rede e confirme-a antes de qualquer discussão sobre produtos. Requisitos ambíguos transformam qualquer comparação de fornecedores numa discussão de preferências.

Avalie as substituições face a esses requisitos

Os serviços de conectividade geridos do Azure e os dispositivos virtuais de rede suportados por fornecedores têm ambos de ser pontuados face à mesma lista. Não assuma que nenhum deles é um equivalente direto de uma VM com RRAS só porque consegue terminar IPsec: o modelo de NAT e a propriedade das rotas e o projeto de alta disponibilidade decidem como os locais existentes se ligam e para onde voltam as suas respostas. Pontue cada candidato em papel face à lista e anote que requisitos não cumpre, porque essa nota é o que torna a escolha revisível mais tarde.

Um balanceador de carga à frente de duas VMs de dispositivo não é alta disponibilidade por si só. Fornece um front-end, não um estado de túnel sincronizado, e um failover que deixa cair todas as sessões é uma decisão de projeto que alguém tem de tomar de propósito. Pergunte ao fornecedor do dispositivo qual é o padrão de HA suportado e se corresponde à disponibilidade prometida aos locais. Teste o failover antes de esses locais dependerem dele, e trate cada sessão perdida como uma constatação e não como uma surpresa.

Onde o requisito é realmente simples — um local, um prefixo, sem sobreposição — um serviço gerido costuma ganhar em custo operacional. Onde a tradução e o encaminhamento dinâmico estão ambos em jogo, o caminho do dispositivo pode ser o único adequado, e essa é uma razão para planear uma migração mais longa em vez de manter a VM não suportada.

Se já existe uma VM com RRAS a correr

A descoberta não é razão para a eliminar. Planeie a mudança em torno das dependências que essa VM acumulou: rotas de que outras sub-redes dependem, regras de NAT que escondem endereços de origem e tudo o que a monitorização aprendeu a esperar do seu endereço. Preserve as rotas necessárias e um caminho de recuperação testado enquanto o destino suportado é desenhado e validado ao lado.

Mantenha a suportabilidade e o diagnóstico técnico como constatações separadas em todo o momento. Uma disposição não suportada também pode ter um erro de encaminhamento comum, e corrigir esse erro não altera o seu estado de suporte. Ambas as afirmações pertencem ao relatório, e nenhuma anula a outra.

Feche o percurso registando a citação de suporte, a lista de requisitos, a substituição escolhida e a ordem de transição. Esses quatro elementos são a primeira coisa que um auditor ou um novo membro da equipa vai pedir.