Monitoramento de Conectividade Híbrida: Laboratório Automatizado com Azure Connection Monitor e Bicep

Garantir a estabilidade da conectividade híbrida entre ambientes locais (on-premises) e a nuvem é um dos maiores desafios para equipes de infraestrutura e redes. Para demonstrar na prática como estruturar, testar e monitorar esses canais de comunicação, eu desenvolvi e disponibilizei um repositório público chamado DemoConnectionMonitor. Este laboratório é 100% automatizado via Infrastructure as Code (IaC) com Bicep e simula uma rede híbrida completa diretamente no Azure.

O laboratório cria duas redes virtuais simulando o ambiente on-premises e o hub do Azure, conecta-as via VPN Gateway (SKUs redundantes em zonas de disponibilidade), estabelece instâncias de testes e implanta o Network Watcher Connection Monitor. Para tornar o cenário realista, o projeto inclui scripts de simulação de falhas (como bloqueios de porta por NSG, rotas com UDR e indisponibilidade de aplicação) e um conjunto de consultas KQL (Kusto Query Language) prontas para análise no Log Analytics.

⟩_ Arquitetura do Laboratório

A infraestrutura de rede simulada é dividida em dois segmentos principais contidos em VNets distintas:

• Simulação On-Premises (vnet-onprem-sim): Espaço de endereçamento 10.10.0.0/16. Contém uma máquina virtual Linux (vm-onprem-sim) que atua como cliente gerador de tráfego.
• Hub Azure (vnet-azure-hub): Espaço de endereçamento 10.20.0.0/16. Hospeda a máquina virtual de destino (vm-azure-hub) que executa serviços web Nginx e iPerf3 para testes de largura de banda.

O tráfego de dados transita através de uma conexão de túnel IPsec gerada por dois VPN Gateways locais (vpngw-onprem-sim e vpngw-azure-hub). A orquestração com Bicep vincula todas as pontas automaticamente, associando public IPs, rotas e associações de emparelhamento (peering) sem necessidade de inserção manual de credenciais.

⟩_ O Bicep para o Connection Monitor

O coração do monitoramento reside no recurso Microsoft.Network/networkWatchers/connectionMonitors. Abaixo está o trecho do template Bicep que utilizei para estruturar os testes de ICMP, HTTP e TCP de ponta a ponta:

resource connectionMonitor 'Microsoft.Network/networkWatchers/connectionMonitors@2023-11-01' = {
  name: '${networkWatcherName}/${connectionMonitorName}'
  location: location
  properties: {
    endpoints: [
      {
        name: 'vm-onprem-sim'
        type: 'AzureVM'
        resourceId: vmOnPremId
      }
      {
        name: 'vm-azure-hub'
        type: 'AzureVM'
        resourceId: vmAzureHubId
      }
    ]
    testConfigurations: [
      {
        name: 'http-8080-app-health'
        protocol: 'Http'
        testFrequencySec: 60
        httpConfiguration: {
          port: 8080
          path: '/health'
          validStatusCodes: [ 200 ]
        }
      }
      {
        name: 'tcp-5201-iperf'
        protocol: 'Tcp'
        testFrequencySec: 30
        tcpConfiguration: {
          port: 5201
        }
      }
    ]
    testGroups: [
      {
        name: 'hybrid-monitoring-group'
        disable: false
        sources: [ 'vm-onprem-sim' ]
        destinations: [ 'vm-azure-hub' ]
        testConfigurations: [ 'http-8080-app-health', 'tcp-5201-iperf' ]
      }
    ]
  }
}

⟩_ Simulação de Falhas e Análise Comportamental

Para demonstrar como as falhas afetam o tráfego e como as ferramentas de monitoramento acusam o problema, incluí três scripts em PowerShell (scripts/) que aplicam perturbações dinâmicas na infraestrutura:

• Bloqueio de Firewall (simulate-nsg-block.ps1): Insere regras restritivas no Network Security Group (NSG) bloqueando portas específicas como TCP 80 (HTTP) e TCP 5201 (iPerf3), mas mantendo o tráfego ICMP (ping) e SSH intactos. Isso ajuda a ilustrar situações comuns de "o servidor responde a ping, mas a aplicação está fora do ar".
• Buraco Negro de Roteamento (simulate-udr-blackhole.ps1): Associa uma tabela de rotas (UDR) maliciosa que direciona o tráfego da subnet para um gateway inexistente, matando toda a conectividade em nível IP.
• Indisponibilidade de Aplicação (simulate-app-outage.ps1): Desliga apenas o serviço do iPerf3 ou Nginx dentro da VM do Azure, forçando o Connection Monitor a alertar falha apenas no teste de saúde HTTP específico da porta 8080, sem perda de pacotes IPsec.

⟩_ Consultando Resultados no Log Analytics via KQL

Todos os resultados de testes e caminhos de rede mapeados pelo agente do Connection Monitor são gravados na tabela NWConnectionMonitorTestResult do Log Analytics. Uma das consultas estruturadas no repositório permite monitorar instantaneamente a perda de pacotes e a latência de cada canal:

// Análise em tempo real de latência e perda de pacotes
NWConnectionMonitorTestResult
| where TimeGenerated > ago(1h)
| summarize 
    TotalChecks = count(),
    FailedChecks = countif(TestResult == "Fail"),
    AvgLatencyMs = avg(RoundTripTimeMs) 
    by ConnectionMonitorName, TestConfigurationName, SourceResourceId
| project 
    ConnectionMonitorName, 
    TestConfigurationName, 
    LossPercentage = (toreal(FailedChecks) / TotalChecks) * 100, 
    AvgLatencyMs

⟩_ Execução Rápida do Laboratório

Para clonar e implantar todo o ecossistema em sua própria subscrição de testes do Azure (tempo médio de deploy: 35 a 40 minutos devido ao tempo de provisionamento físico do VPN Gateway), execute os seguintes comandos no terminal PowerShell 7+:

# Clonar o repositório
git clone https://github.com/micheljatuba/DemoConnectionMonitor.git
cd DemoConnectionMonitor

# Iniciar o deploy automatizado para uma região à sua escolha
./scripts/deploy.ps1 -Location eastus2

# Importar as consultas KQL como pesquisas salvas no Log Analytics (opcional)
./scripts/import-saved-searches.ps1

O script detecta sua chave pública SSH local, gera uma chave compartilhada segura para fechar a conexão IPsec dos Gateways de VPN, e cria alertas integrados para cada falha gerada. Quando terminar o laboratório de testes, execute ./scripts/cleanup.ps1 para deletar todas as instâncias e evitar custos recorrentes desnecessários.