IP estático no Azure P2S VPN: por que o endereço do cliente muda

Cada cliente do Azure point-to-site recebe um endereço do pool quando se autentica, e mantém-no apenas enquanto durar essa conexão. Não há tabela de reservas, nem mapeamento por usuário, nem configuração de gateway que signifique «dê sempre 172.16.0.10 a esta pessoa». Esse único mecanismo explica os dois sintomas com que as pessoas se deparam mais tarde: uma regra de NSG que deixa de corresponder a um usuário a quem antes correspondia, e uma lista de permitidos que admite em silêncio uma máquina que ninguém acrescentou de propósito. Substituir a regra por uma regra IP mais engenhosa não corrige nenhum dos dois, porque aquilo que a regra nomeia é reatribuído segundo um calendário que você não controla.

O pool é capacidade, não identidade. Existe para que os túneis simultâneos obtenham endereços únicos, e recicla-os no momento em que um arrendamento termina. Quando isso fica claro, a pergunta útil deixa de ser «como fixo este cliente» e passa a ser «contra o que posso escrever uma regra que o gateway não recicle».

O que o gateway realmente faz quando um cliente se conecta

O gateway mantém o pool de endereços de cliente configurado e trata-o como uma tabela de arrendamentos. Ao conectar, pega o próximo endereço livre, na prática o mais baixo disponível, e atribui-o ao adaptador do túnel até o cliente se desconectar ou o arrendamento expirar. A ordem decide, não a identidade: quem se reconecta primeiro após um período calmo fica com o endereço mais baixo que por acaso esteja livre naquele momento.

O tamanho do pool esconde o comportamento. Um pool de laboratório um ou dois endereços maior do que o número de testadores parece determinístico, porque o mesmo portátil tende a reconectar-se na mesma ordem todas as manhãs. Acrescente uma terceira máquina, altere o tamanho do pool ou deixe uma sessão ligada durante o almoço, e o padrão quebra. O endereço nunca foi estável; a fila é que era.

Qualquer alteração na configuração point-to-site também reinicia o espaço de arrendamentos. Um tipo de autenticação diferente, um pool redimensionado, um novo intervalo de pool ou um gateway demolido e reconstruído enviam todos os clientes de volta para um pool que já não corresponde aos seus endereços antigos. Nada dessa alteração toca na sua NSG, e é por isso que a avaria parece espontânea.

Pode vê-lo acontecer em cerca de um minuto. Ligue-se, anote o endereço do túnel nos detalhes de ligação do cliente, desligue-se, ligue uma segunda máquina e volte a ligar a primeira. O endereço que recebe de volta depende do que a segunda máquina estiver a segurar, e nenhuma definição do portal restaurará o anterior a pedido.

Uma NSG baseada no IP do cliente é, na realidade, uma regra sobre a ordem de ligação

A regra que as pessoas escrevem primeiro é a óbvia: uma regra de entrada na NIC da VM de gestão ou na sua sub-rede, com o endereço interno do cliente VPN como origem. É curta, passa o teste no dia em que é escrita e falha assim que o pool tem mais do que um endereço livre.

Daí resultam dois modos de falha, e apenas um parece um erro. Um utilizador legítimo é recusado porque outra pessoa tem naquele momento o endereço que a regra nomeia, e isso chega como um incómodo pedido de suporte. Ou um utilizador não previsto é admitido porque herdou um endereço em que a regra ainda confia, e isso não chega como nada até alguém auditar o acesso.

Como a regra segue o arrendamento, a política efetiva lê-se «a primeira pessoa a ligar-se obtém acesso de gestão». Isso é uma descrição da ordem de ligação vestida de intenção, e nenhuma higiene de regras a torna uma expressão de intenção.

O arrendamento do cliente e o endereço do gateway são objetos diferentes

A maior parte da confusão vem de uma palavra. O gateway tem um IP público relativamente estável; os clientes têm endereços privados do pool que não são. Para um gateway VPN não redundante por zonas, o IP público é atribuído dinamicamente, mas sobrevive a um redimensionamento, a um reinício e à manutenção de rotina — muda quando o próprio gateway é eliminado e recriado. As SKU de gateway redundantes por zonas e zonais usam um IP público de SKU Standard, e essa atribuição tem de ser estática.

É essa estabilidade que um par local precisa na sua configuração, e não diz nada sobre identificar um cliente individual. Quando um parceiro pergunta que endereço vai ver, a resposta é o IP público do gateway em site-to-site, ou um intervalo NAT partilhado — nunca o arrendamento do túnel de um portátil.

Os pools de grupo dão-lhe um intervalo contra o qual vale a pena escrever regras

O Virtual WAN point-to-site suporta grupos de utilizadores, e a cada grupo pode ser atribuído o seu próprio pool de endereços de cliente. A pertença é decidida pela identidade, por isso o intervalo onde um cliente cai torna-se previsível: operações num intervalo, prestadores noutro, e o intervalo é algo que uma regra de firewall ou de NSG pode nomear sem adivinhar.

O conjunto de regras resultante tem uma forma que pode rever:

• um pool por público, dimensionado para picos de sessões simultâneas e não pelo número de pessoas;
• a pertença ao grupo tratada pela identidade, não editando regras sempre que alguém se junta;
• regras de NSG ou do Azure Firewall escritas contra intervalos de pool, nunca contra arrendamentos individuais;
• um hub ou gateway separado para públicos que nunca devem partilhar um intervalo.

Pôr um pool inteiro na lista de permitidos é honesto mas grosseiro: cada cliente ligado nesse intervalo obtém o mesmo acesso. É uma decisão de política que merece ser dita em voz alta em vez de descoberta numa revisão. Tudo o que ainda exige uma resposta por pessoa pertence ao recurso, através de atribuições de funções, não ao filtro de pacotes.

Quando a implementação não pode passar para o Virtual WAN

Muitos gateways continuam a ser gateways VPN simples, e passar para o Virtual WAN não é uma alteração trivial. A resposta prática é mover a decisão por utilizador do filtro de pacotes para algo que já saiba quem é o utilizador.

A identidade ao nível do recurso é a versão mais barata. Storage, SQL e Key Vault suportam todos autenticação Entra ID com atribuições de funções por utilizador ou por grupo, pelo que a VPN só tem de provar alcance de rede. Um anfitrião de salto com contas nominais faz o mesmo trabalho para tarefas administrativas, porque o anfitrião registra a pessoa e o túnel apenas transporta pacotes. Registar os clientes no DNS e permitir o nome em vez do número sobe a regra um nível. A identidade ao nível da aplicação — um sujeito de certificado, uma declaração de token, uma pertença a grupo — funciona quando é a aplicação, e não a rede, a ser chamada a decidir.

Para um parceiro que insiste num endereço de origem fixo, a resposta é site-to-site ou ExpressRoute com um prefixo de par definido. Eles permitem o prefixo de par, o endereço que aparece do lado deles pertence ao gateway e não muda quando alguém reinicia um portátil.

Verifique o pool antes de editar outra lista de permitidos

Duas propriedades do pool causam a maior parte do comportamento que as pessoas atribuem ao cliente. Um pool demasiado pequeno recicla arrendamentos depressa, pelo que os endereços parecem mover-se constantemente e qualquer regra baseada em endereço parece instável por construção. Um pool que se sobrepõe aos intervalos locais ou ao espaço de endereços da rede virtual cria uma ambiguidade de encaminhamento que nenhuma regra de firewall repara.

Coloque três coisas numa página antes de tocar numa regra: o pool point-to-site, o espaço de endereços da rede virtual e os intervalos locais. Não devem sobrepor-se, e o pool precisa de espaço para cada cliente simultâneo mais uma margem para reconexões.

Depois feche o ciclo nesta ordem:

• Ligue-se a partir de duas máquinas nas duas ordens e compare os endereços; se puderem trocar, nenhuma regra baseada em endereço é segura.
• Verifique se o gateway é de Virtual WAN; se for, use pools de grupo em vez de regras por endereço.
• Pergunte o que acontece quando uma regra atinge a pessoa errada; se a resposta for um incidente de acesso, mova o controlo para a identidade.
• Registe que intervalo pertence a que grupo no mesmo repositório das definições de NSG.
• Volte a testar após qualquer alteração de pool, autenticação ou gateway, porque essas alterações reescrevem o mapeamento sem o anunciar.