Uma VM do Azure precisa do túnel: cliente convidado ou gateway VPN?

Uma carga de trabalho numa VM do Azure tem de chegar a uma rede privada através de um túnel. A pergunta que decide o desenho não é qual produto VPN é melhor, mas se alguma outra máquina vai precisar desse caminho. Responda a isso primeiro e o resto da arquitetura costuma escolher-se sozinho. Se errar, herda uma VM que se tornou silenciosamente num router que ninguém documentou.

Duas tarefas que se parecem

Uma VM pode ser um ponto final ou um ponto de trânsito, e a diferença não está no software que instala mas em quem consome o túnel. Como ponto final, o convidado executa um cliente para os seus próprios processos. Como ponto de trânsito, encaminha pacotes de outras cargas de trabalho, o que a torna parte da topologia de rede.

A maioria dos pedidos para uma única VM é a primeira tarefa vestida com a linguagem da segunda. Alguém diz «a VM é a nossa VPN» quando quer dizer que uma aplicação nela precisa de chegar a uma base de dados do outro lado.

Condição um: algo mais precisa do lado remoto?

Se a resposta for não, instale o cliente no convidado e pare de desenhar. Nada nessa escolha exige o gateway gerido, e nada nela transforma a VM num gateway para os vizinhos. Está a acrescentar uma rota dentro de um único sistema operativo.

Se a resposta for sim, ou provavelmente sim dentro de um ano, trate isso agora como desenho de rede. Outras VMs só chegam a uma VM de trânsito quando a tabela de rotas da sub-rede as envia para lá e a NIC aceita o tráfego encaminhado, por isso o trabalho é tabelas de rotas e permissões de encaminhamento, não outra instalação de cliente.

Condição dois: consegue manter o caminho de administração?

Um cliente VPN que instala uma rota ampla pode capturar o caminho que usa para administrar a VM. Se a lista de destinos do túnel se sobrepuser à rede de gestão, a sua sessão SSH ou RDP cai no momento em que o cliente liga, e a correção tem de ser aplicada pela consola série ou por uma reconstrução.

Verifique antes e depois. No Linux, ip route get <management-ip> indica que interface e origem o kernel usaria agora; compare com a resposta enquanto o túnel está ativo. Um túnel dividido com uma lista explícita de destinos é mais fácil de defender do que uma rota predefinida, e costuma ser o que a carga de trabalho realmente precisa.

Condição três: quem o corrige à meia-noite?

Um cliente convidado é o seu sistema operativo, a sua versão de cliente e os seus certificados. Isso está bem quando já opera a VM e o seu ciclo de correções. É uma má troca quando a VM só existe para segurar o túnel. Conte as horas de correção antes de chamar mais barato ao cliente convidado. Uma atualização de cliente que exige reinício é uma interrupção que agendou para uma máquina que existe para manter o túnel de pé.

O gateway gerido move essa manutenção para a plataforma. Continua a ser dono da identidade, da autorização e dos caminhos de rede por trás, mas não reinicia uma máquina para aplicar uma atualização de cliente.

O que o gateway gerido não faz

O Azure VPN Gateway é um serviço de conetividade de VNet com os seus próprios esquemas site-to-site e point-to-site. Não é uma regra que proíba software VPN no convidado nem é um substituto direto de um cliente de que uma aplicação precisa.

O que oferece é uma ligação na camada de rede, alcançável por muitas cargas de trabalho através de encaminhamento. O que não oferece é um túnel usado por apenas um processo numa VM, limitado à identidade desse processo. Esse âmbito não é uma limitação de que se deva pedir desculpa; é exatamente o sentido do desenho com cliente convidado. Uma aplicação, uma rota, um conjunto de credenciais, nenhum efeito nas outras VMs da sub-rede.

Portanto a comparação não é gerido contra software. É conetividade com âmbito de rede contra conetividade com âmbito de processo, e a segunda é legítima quando só um processo precisa dela.

Planeie o caminho de crescimento antes de precisar dele

Se o requisito crescer de uma VM para uma sub-rede, reconstrua o desenho em vez de alargar os prefixos permitidos do cliente. Reutilizar uma sessão conveniente como router não documentado liga cada consumidor à vida dessa VM, às suas credenciais e à sua janela de correções.

O ponto de partida correto, uma vez que a ligação é de âmbito de rede e não de carga de trabalho, é a descrição geral do Azure VPN Gateway.

Antes de escolher, escreva três linhas: o que precisa do lado remoto, quem administra a VM e quem corrige o túnel. Se as três respostas apontarem para uma só carga de trabalho, um cliente convidado é o desenho honesto. Se alguma delas apontar para uma sub-rede, desenhe já a camada de rede.