Monitorizare VPN Azure Site: asociați starea tunelului cu o sondă reală

Fiecare panou este verde, tunelul este activ de unsprezece zile, iar sucursala nu poate încărca aplicația internă. Acesta este simptomul pentru care există acest design și nu este o eroare de monitorizare. Starea tunelului răspunde la o întrebare despre negociere, în timp ce utilizatorul întreabă despre o cerere care traversează patru decizii de rutare și un strat de politici. Aveți nevoie de ambele semnale, ținute separat, și de o modalitate de a le distinge în miezul nopții.

Începeți de la simptomul care eșuează, nu de la tunel

O asociere de securitate stabilită înseamnă că părțile au convenit asupra unei propuneri și au instalat chei. Nu înseamnă că selectorii acoperă subrețeaua de care are nevoie utilizatorul, că partea îndepărtată are o rută de întoarcere sau că un firewall acceptă portul după decriptare. Traficul poate eșua și pe partea sucursalei a tunelului, iar atunci Azure nu vede nimic și raportează sănătate perfectă. Metrica tunelului este necesară și niciodată suficientă.

Trei stări trebuie să fie distinse: tunelul este căzut, tunelul este activ iar serviciul eșuează, și sursa de monitorizare în sine nu este disponibilă.

Puneți sonda acolo unde sunt utilizatorii

Pentru o aplicație din sucursală către Azure, rulați testul sintetic de pe un gazdă din rețeaua de încărcare a sucursalei și îndreptați-l spre punctul de intrare HTTPS privat pe care utilizatorii îl folosesc cu adevărat. O sondă lansată din gateway folosește o altă adresă sursă și adesea o altă cale de politică, așa că poate trece în timp ce fiecare utilizator eșuează. Azure Connection Monitor acceptă verificări TCP, ICMP și HTTP cu grupuri de test și praguri, iar sursele locale au cerințe de agent diferite de cele din partea Azure. Verificați configurația acceptată în prezent în loc să copiați dintr-un blog o rețetă clasică de monitorizare retrasă.

Țineți sonda îngustă și plictisitoare: o destinație, un port, o frecvență care corespunde cerinței operaționale și o regulă explicită de permisiune pentru acea sursă.

Alegeți o verificare care se potrivește serviciului

O conexiune TCP la portul serviciului dovedește accesibilitatea transportului prin tunel și nu spune nimic despre TLS sau despre aplicație. O verificare HTTP adaugă o așteptare de stare și prinde un ascultător care acceptă conexiuni dar nu poate servi, care este eșecul mai frecvent după o schimbare de certificat sau de backend. Niciuna nu este o tranzacție de afaceri autentificată dacă testul nu autentifică efectiv, așa că nu o etichetați astfel pe panou. Alegeți verificarea care eșuează când apare reclamația utilizatorului.

ICMP este cea mai slabă dintre cele trei opțiuni, deoarece multe stive îl aruncă prin politică și un ping eșuat dovedește foarte puțin.

Aduceți ambele semnale în Elastic fără a le inventa

Gatewayul VPN emite metrici de platformă precum octeții de ieșire și intrare ai tunelului și contoarele de pierdere a pachetelor și poate trimite jurnale de diagnostic în categorii care includ evenimente de tunel și IKE. Rezultatele Connection Monitor ajung prin Azure Monitor ca metrici și printr-un spațiu de lucru Log Analytics ca înregistrări de jurnal. Nimic din toate acestea nu apare de la sine într-un index Elastic. Alegeți o conductă acceptată pentru metrici și una pentru jurnale, de obicei intrarea Azure Event Hub sau integrarea Azure Monitor, și verificați ce ingeră de fapt integrarea instalată înainte de a avea încredere în modelul indexului.

Păstrați etichetele care îi permit unui operator să unească cele două seturi de date: punctul final sursă, destinația, protocolul și portul pentru sondă, și identitatea tunelului plus adresa partenerului pentru gateway.

Validați conducta cu un singur eveniment controlat, apoi căutați-l în Elastic și verificați marcajul de timp și etichetele resurselor. Un document cu marcaj de timp greșit este mai rău decât unul lipsă, pentru că face datele vechi să pară actuale.

Alarmați pe diferență, nu pe culoare

Sensul celor două semnale sunt combinațiile. Tunel căzut ar trebui să alerteze proprietarul rețelei; tunel activ cu o sondă care eșuează pe proprietarul aplicației; un rezultat de sondă lipsă pe cel care deține agentul de monitorizare. Unirea tuturor trei într-un singur panou roșu garantează că alerta va fi redusă la tăcere într-o lună. Alarmați pe eșec susținut cu o fereastră de persistență, nu pe o singură eșantionare, și adăugați o verificare separată pentru sănătatea conductei de ingestie în sine.

Un panou plin de eșantioane reușite de ieri nu ar trebui citit ca o cale sănătoasă astăzi.

Scris, contractul este mic: metrica tunelului spune că gatewayul a negociat, sonda spune că calea funcționează de acolo unde stau utilizatorii, iar sănătatea conductei spune dacă vreunul dintre răspunsuri este actual. Orice altceva pe panou este comentariu.