VPN Gateway Point-to-Site: Migração de Certificado Antes de 31/01/2027

Se você usa VPN Gateway Point-to-Site no Azure, provavelmente recebeu (ou vai receber) um aviso da Microsoft: a partir de fevereiro de 2027, o Azure vai migrar os certificados de gateway referenciados pelos perfis de cliente P2S. Quem não redistribuir o client profile atualizado até 31 de janeiro de 2027 corre o risco real de usuários e dispositivos pararem de conseguir se conectar.

Este artigo da série artigos-network sobre VPN Gateway Point-to-Site explica o que exatamente está sendo descontinuado, por que isso quebra conexões existentes se ninguém agir, e o passo a passo pra migrar antes do prazo — sem drama, é uma ação simples, mas fácil de esquecer até ser tarde demais.

Sumário

• O que é VPN Gateway Point-to-Site
• O que exatamente está sendo migrado
• Por que isso quebra conexões se ninguém agir
• A configuração P2S no Terraform
• Como identificar se você é afetado
• Como baixar e redistribuir o client profile atualizado
• Checklist antes de 31/01/2027
• Conclusão
• Referências oficiais

O que é VPN Gateway Point-to-Site

O VPN Gateway Point-to-Site (P2S) é um dos três modos de conexão do Azure VPN Gateway (os outros são Site-to-Site, coberto no artigo anterior sobre ExpressRoute vs VPN Gateway, e VNet-to-VNet). Em vez de conectar dois roteadores — um datacenter inteiro a uma VNet —, o P2S conecta um dispositivo individual (o notebook de um desenvolvedor, por exemplo) diretamente a uma VNet do Azure, via cliente VPN instalado na máquina.

Pra isso funcionar, cada usuário baixa um client profile — um pacote de configuração gerado pelo próprio VPN Gateway, contendo o endereço do gateway, os certificados necessários pra autenticação e as regras de roteamento. É esse pacote que a mudança da Microsoft afeta.

O que exatamente está sendo migrado

Vale separar dois certificados diferentes que aparecem numa configuração de VPN Gateway Point-to-Site, porque é fácil confundir os dois:

• Certificado raiz/cliente de autenticação — o que você mesmo gerencia quando usa autenticação por certificado (o root_certificate no Terraform, mostrado mais abaixo). Esse não é o afetado pelo aviso.
• Certificado de gateway — o certificado TLS interno usado pelo próprio serviço de VPN Gateway da Microsoft para estabelecer o túnel com o cliente. É esse que está sendo migrado a partir de fevereiro/2027, e é ele que fica referenciado dentro do client profile que cada usuário baixou.

Ou seja: mesmo que sua configuração de autenticação (certificado próprio, Azure AD/Entra ID, ou RADIUS) não mude em nada, o client profile antigo aponta pra referências do certificado de gateway que deixarão de ser válidas depois da migração.

Por que isso quebra conexões se ninguém agir

No VPN Gateway Point-to-Site, o client profile não é dinâmico — ele é um pacote estático baixado uma vez e instalado no dispositivo do usuário. Se a infraestrutura de certificado por trás dele mudar e ninguém gerar e redistribuir um profile novo, o cliente VPN vai tentar validar o túnel contra uma referência que não bate mais com o que o gateway está usando, e a conexão falha silenciosamente — geralmente sem uma mensagem de erro óbvia do lado do usuário, o que torna esse tipo de mudança fácil de descobrir tarde, via chamado de suporte, em vez de planejada.

A configuração P2S no Terraform

A configuração do VPN Gateway Point-to-Site vive dentro do próprio recurso azurerm_virtual_network_gateway — não é um recurso separado. Em vez de declarar esse recurso cru em cada artigo, este Terraform compõe a partir de uma biblioteca de módulos reutilizáveis: terraform-resource-group-modules, terraform-virtual-network-modules e terraform-public-ip-modules (já existentes) mais um novo terraform-vpn-gateway-modules, que expõe o bloco vpn_client_configuration — pool de IPs dos clientes, protocolos aceitos e, no caso de autenticação por certificado, o certificado raiz:

module "vpn_gateway_p2s" {
  source = "../../terraform-vpn-gateway-modules"

  name                 = "vpngw-p2s-blog-castilho"
  resource_group_name  = module.rg.name
  location             = var.location
  gateway_subnet_id    = module.vnet.subnets["gateway"].id
  public_ip_address_id = module.pip_vpn_gateway.id
  sku                  = "VpnGw1AZ" # VpnGw1 (não-AZ) foi descontinuado, ver artigo sobre ExpressRoute vs VPN Gateway

  vpn_client_configuration = {
    address_space        = [var.p2s_address_pool]
    vpn_client_protocols = ["OpenVPN"]
    vpn_auth_types       = ["Certificate"]

    root_certificates = [{
      name             = var.root_cert_name
      public_cert_data = file(var.root_cert_public_data_path)
    }]
  }

  tags = var.tags
}

Esse root_certificates é o certificado de autenticação que você controla — não é o certificado de gateway afetado pela migração da Microsoft. O Terraform não tem (nem precisa ter) nenhum recurso pra lidar com o certificado de gateway: ele é gerenciado inteiramente pela plataforma. A ação de migração é operacional (baixar e redistribuir o client profile), não uma mudança de infraestrutura declarada em código.

Vale notar o desenho do módulo: terraform-vpn-gateway-modules não força a configuração P2S — o campo vpn_client_configuration é opcional (null por padrão). O mesmo módulo é reaproveitado no artigo sobre ExpressRoute vs VPN Gateway para o cenário site-to-site, sem esse bloco.

terraform validate e terraform plan confirmam os 5 recursos (Resource Group, VNet, GatewaySubnet, IP público, VPN Gateway com vpn_client_configuration) sem erros:

terraform init -backend-config=backend.hcl
terraform plan -out=tfplan.out
# Plan: 5 to add, 0 to change, 0 to destroy.

Como identificar se você é afetado

Se você tem algum VPN Gateway Point-to-Site configurado, você é afetado — independente de qual tipo de autenticação usa. Liste os VPN Gateways da subscription e confira quais têm configuração de cliente:

az network vnet-gateway list \
  --query "[].{name:name, resourceGroup:resourceGroup, vpnClientAddressPool:vpnClientConfiguration.vpnClientAddressPool.addressPrefixes}" \
  -o table

Num VPN Gateway Point-to-Site, qualquer gateway com um pool de endereços preenchido nessa saída tem P2S ativo e precisa da redistribuição do client profile antes do prazo.

Como baixar e redistribuir o client profile atualizado

Pra quem usa VPN Gateway Point-to-Site, a ação recomendada pela Microsoft é simples: baixar o client profile atualizado e redistribuir pra todos os usuários e dispositivos afetados antes de 31/01/2027. Via CLI:

az network vnet-gateway vpn-client generate \
  --resource-group  \
  --name  \
  --authentication-method EAPTLS \
  --output tsv

O comando devolve uma URL temporária de download do pacote de configuração (.zip), que contém os instaladores do cliente VPN pra Windows (32 e 64 bits) e a configuração exportável pra outras plataformas (macOS, Linux, iOS, Android — depende do tipo de autenticação configurada). O mesmo fluxo está disponível no portal: VPN Gateway → Point-to-site configuration → Download VPN client.

Nessa migração de VPN Gateway Point-to-Site, a parte que exige planejamento não é técnica, é operacional: identificar todos os usuários/dispositivos com o profile antigo instalado e garantir que cada um receba e instale o novo antes do prazo — especialmente relevante em ambientes com muitos usuários remotos ou dispositivos gerenciados por terceiros.

Checklist antes de 31/01/2027

• Levantar todos os VPN Gateways com P2S ativo na organização (az network vnet-gateway list)
• Mapear quem usa cada gateway — lista de usuários/dispositivos, não só quantidade
• Baixar o client profile atualizado de cada gateway afetado
• Definir o canal de redistribuição (MDM/Intune, e-mail interno, portal de autoatendimento — o que já existir na organização)
• Comunicar o prazo aos usuários com antecedência, não na véspera
• Confirmar que conexões continuam funcionando após a instalação do profile novo, antes de considerar a migração concluída

Conclusão

A migração de certificado de gateway do VPN Gateway Point-to-Site é o tipo de aviso que é fácil de arquivar mentalmente como “resolvo depois” — o prazo é longo (mais de um ano a partir do anúncio) e nada quebra hoje. Mas no VPN Gateway Point-to-Site, é exatamente esse tipo de prazo distante que costuma virar incidente de última hora: vale tratar como qualquer outro item de manutenção de infraestrutura com data — registrar, atribuir um responsável e agendar a ação bem antes de 31/01/2027, não na semana anterior.

Referências oficiais

• About Point-to-Site VPN — Microsoft Learn
• Configure P2S VPN client certificate authentication — Microsoft Learn
• azurerm_virtual_network_gateway — Terraform Registry

Interessado em saber mais sobre esse assunto?