Monitorización de VPN de Azure Site: empareje el estado del túnel con una sonda real

Todos los paneles están en verde, el túnel lleva once días activo y la sucursal no puede cargar la aplicación interna. Ese es el síntoma para el que existe este diseño, y no es un fallo de monitorización. El estado del túnel responde a una pregunta sobre la negociación, mientras que el usuario pregunta por una petición que cruza cuatro decisiones de enrutamiento y una capa de directivas. Necesita ambas señales, por separado, y una forma de distinguirlas de madrugada.

Empiece por el síntoma que falla, no por el túnel

Una asociación de seguridad establecida significa que los pares acordaron una propuesta e instalaron claves. No significa que los selectores cubran la subred que necesita el usuario, que el lado remoto tenga una ruta de retorno o que un cortafuegos acepte el puerto tras el descifrado. El tráfico también puede fallar en el lado de la sucursal del túnel, y entonces Azure no ve nada e informa de una salud perfecta. La métrica del túnel es necesaria y nunca es suficiente.

Hay que poder distinguir tres estados: el túnel está caído, el túnel está activo y el servicio falla, y la propia fuente de monitorización no está disponible.

Coloque la sonda donde están los usuarios

Para una aplicación de sucursal a Azure, ejecute la prueba sintética desde un host en la red de carga de trabajo de la sucursal y apúntela al punto de entrada HTTPS privado que los usuarios realmente usan. Una sonda lanzada desde la puerta de enlace usa otra dirección de origen y a menudo otra ruta de directiva, así que puede pasar mientras todos los usuarios fallan. Azure Connection Monitor admite comprobaciones TCP, ICMP y HTTP con grupos de prueba y umbrales, y sus orígenes locales tienen requisitos de agente distintos a los del lado de Azure. Compruebe la disposición admitida actualmente en lugar de copiar una receta clásica de monitorización retirada de un blog.

Mantenga la sonda estrecha y aburrida: un destino, un puerto, una frecuencia que coincida con el requisito operativo y una regla de permiso explícita para ese origen.

Elija una comprobación que encaje con el servicio

Una conexión TCP al puerto del servicio demuestra alcanzabilidad de transporte por el túnel y no dice nada sobre TLS ni la aplicación. Una comprobación HTTP añade una expectativa de estado y detecta un escucha que acepta conexiones pero no puede servir, que es el fallo más habitual tras un cambio de certificado o de backend. Ninguna de las dos es una transacción de negocio autenticada si la prueba no autentica de verdad, así que no la etiquete como tal en el panel. Elija la comprobación que falla cuando ocurre la queja del usuario.

ICMP es la opción más débil de las tres, ya que muchas pilas lo descartan por política y un ping fallido demuestra muy poco.

Lleve ambas señales a Elastic sin inventarlas

La puerta de enlace VPN emite métricas de plataforma como bytes de salida y entrada del túnel y contadores de paquetes descartados, y puede enviar registros de diagnóstico en categorías que incluyen eventos de túnel e IKE. Los resultados de Connection Monitor llegan por Azure Monitor como métricas y por un área de trabajo de Log Analytics como registros. Nada de eso aparece por sí solo en un índice de Elastic. Elija una canalización admitida para las métricas y otra para los registros, normalmente la entrada de Azure Event Hub o la integración de Azure Monitor, y verifique qué ingiere realmente la integración instalada antes de confiar en el patrón de índice.

Conserve las etiquetas que permiten a un operador unir los dos conjuntos de datos: punto final de origen, destino, protocolo y puerto para la sonda, e identidad del túnel más dirección del par para la puerta de enlace.

Valide la canalización con un evento controlado, luego búsquelo en Elastic y compruebe su marca de tiempo y sus etiquetas de recursos. Un documento con la marca de tiempo equivocada es peor que uno ausente, porque hace que los datos obsoletos parezcan actuales.

Alerte sobre la diferencia, no sobre el color

El sentido de mantener dos señales son las combinaciones. Túnel caído debería avisar al responsable de red; túnel activo con una sonda que falla al responsable de la aplicación; un resultado de sonda ausente a quien sea dueño del agente de monitorización. Fundir las tres en un solo panel rojo garantiza que la alerta se silencie en un mes. Alerte sobre un fallo sostenido con una ventana de persistencia en lugar de una sola muestra, y añada una comprobación aparte para la salud de la propia canalización de ingesta.

Un panel lleno de muestras correctas de ayer no debería leerse como una ruta sana hoy.

Escrito, el contrato es pequeño: la métrica del túnel dice que la puerta de enlace negoció, la sonda dice que la ruta funciona desde donde se sientan los usuarios, y la salud de la canalización dice si cualquiera de las dos respuestas está al día. Todo lo demás en el panel es comentario.