Monitorização de VPN do Azure Site: combine o estado do túnel com uma sonda real

Todos os painéis estão verdes, o túnel está ativo há onze dias e a filial não consegue carregar a aplicação interna. Esse é o sintoma para o qual este desenho existe, e não é um defeito de monitorização. O estado do túnel responde a uma pergunta sobre a negociação, enquanto o utilizador pergunta por um pedido que atravessa quatro decisões de encaminhamento e uma camada de políticas. Precisa dos dois sinais, separados, e de uma forma de os distinguir pela madrugada.

Comece pelo sintoma que falha, não pelo túnel

Uma associação de segurança estabelecida significa que os pares acordaram uma proposta e instalaram chaves. Não significa que os seletores cubram a sub-rede de que o utilizador precisa, que o lado remoto tenha uma rota de retorno ou que uma firewall aceite a porta após a desencriptação. O tráfego também pode falhar no lado da filial do túnel, e então o Azure não vê nada e reporta saúde perfeita. A métrica do túnel é necessária e nunca suficiente.

É preciso distinguir três estados: o túnel está em baixo, o túnel está ativo e o serviço falha, e a própria fonte de monitorização está indisponível.

Coloque a sonda onde estão os utilizadores

Para uma aplicação de filial para Azure, execute o teste sintético a partir de um anfitrião na rede de carga de trabalho da filial e aponte-o ao ponto de entrada HTTPS privado que os utilizadores realmente atingem. Uma sonda lançada a partir do gateway usa outro endereço de origem e muitas vezes outro caminho de política, pelo que pode passar enquanto todos os utilizadores falham. O Azure Connection Monitor suporta verificações TCP, ICMP e HTTP com grupos de teste e limites, e as suas origens locais têm requisitos de agente diferentes dos do lado Azure. Verifique a disposição atualmente suportada em vez de copiar de um blog uma receita clássica de monitorização retirada.

Mantenha a sonda estreita e aborrecida: um destino, uma porta, uma frequência que corresponda ao requisito operacional e uma regra de permissão explícita para essa origem.

Escolha uma verificação que corresponda ao serviço

Uma ligação TCP à porta do serviço prova a alcançabilidade do transporte pelo túnel e não diz nada sobre TLS ou sobre a aplicação. Uma verificação HTTP acrescenta uma expectativa de estado e apanha um ouvinte que aceita ligações mas não consegue servir, que é a falha mais comum após uma mudança de certificado ou de backend. Nenhuma delas é uma transação de negócio autenticada se o teste não autenticar de facto, por isso não a rotule como tal no painel. Escolha a verificação que falha quando ocorre a queixa do utilizador.

O ICMP é a opção mais fraca das três, já que muitas pilhas o descartam por política e um ping falhado prova muito pouco.

Leve os dois sinais ao Elastic sem os inventar

O gateway VPN emite métricas de plataforma como bytes de saída e entrada do túnel e contadores de pacotes descartados, e pode enviar registos de diagnóstico em categorias que incluem eventos de túnel e IKE. Os resultados do Connection Monitor chegam pelo Azure Monitor como métricas e por uma área de trabalho do Log Analytics como registos. Nada disso aparece sozinho num índice Elastic. Escolha um pipeline suportado para as métricas e outro para os registos, normalmente a entrada Azure Event Hub ou a integração Azure Monitor, e verifique o que a integração instalada realmente ingere antes de confiar no padrão do índice.

Conserve as etiquetas que permitem a um operador juntar os dois conjuntos de dados: ponto final de origem, destino, protocolo e porta para a sonda, e identidade do túnel mais endereço do par para o gateway.

Valide o pipeline com um evento controlado, depois procure-o no Elastic e verifique o timestamp e as etiquetas de recursos. Um documento com o timestamp errado é pior do que um ausente, porque faz dados antigos parecerem atuais.

Alarme sobre a diferença, não sobre a cor

O sentido de manter dois sinais são as combinações. Túnel em baixo deve avisar o responsável de rede; túnel ativo com uma sonda a falhar o responsável da aplicação; um resultado de sonda em falta quem for dono do agente de monitorização. Juntar os três num único painel vermelho garante que o alerta será silenciado num mês. Alarme sobre uma falha sustentada com uma janela de persistência em vez de uma única amostra, e acrescente uma verificação separada para a saúde do próprio pipeline de ingestão.

Um painel cheio de amostras bem-sucedidas de ontem não deve ser lido como um caminho saudável hoje.

Por escrito, o contrato é pequeno: a métrica do túnel diz que o gateway negociou, a sonda diz que o caminho funciona de onde os utilizadores estão sentados, e a saúde do pipeline diz se qualquer das respostas está atual. Tudo o resto no painel é comentário.