Monitoraggio VPN di Azure Site: abbinare lo stato del tunnel a una sonda reale

Ogni pannello è verde, il tunnel è attivo da undici giorni e la filiale non riesce a caricare l’applicazione interna. È il sintomo per cui esiste questo progetto, e non è un difetto di monitoraggio. Lo stato del tunnel risponde a una domanda sulla negoziazione, mentre l’utente chiede di una richiesta che attraversa quattro decisioni di instradamento e uno strato di criteri. Servono entrambi i segnali, tenuti separati, e un modo per distinguerli a notte fonda.

Partite dal sintomo che fallisce, non dal tunnel

Un’associazione di sicurezza stabilita significa che i peer hanno concordato una proposta e installato chiavi. Non significa che i selettori coprano la sottorete che serve all’utente, che il lato remoto abbia una rotta di ritorno o che un firewall accetti la porta dopo la decifratura. Il traffico può fallire anche sul lato filiale del tunnel, e allora Azure non vede nulla e riporta salute perfetta. La metrica del tunnel è necessaria e mai sufficiente.

Tre stati devono essere distinguibili: il tunnel è giù, il tunnel è su e il servizio fallisce, e la sorgente di monitoraggio stessa non è disponibile.

Mettete la sonda dove sono gli utenti

Per un’applicazione da filiale ad Azure, eseguite il test sintetico da un host nella rete di carico della filiale e puntatelo al punto di ingresso HTTPS privato che gli utenti raggiungono davvero. Una sonda lanciata dal gateway usa un altro indirizzo sorgente e spesso un altro percorso di criteri, quindi può passare mentre ogni utente fallisce. Azure Connection Monitor supporta controlli TCP, ICMP e HTTP con gruppi di test e soglie, e le sue sorgenti locali hanno requisiti agente diversi da quelli lato Azure. Verificate la disposizione attualmente supportata invece di copiare da un blog una ricetta classica di monitoraggio ritirata.

Mantenete la sonda stretta e noiosa: una destinazione, una porta, una frequenza che corrisponda al requisito operativo e una regola di autorizzazione esplicita per quella sorgente.

Scegliete un controllo che corrisponda al servizio

Una connessione TCP alla porta del servizio dimostra la raggiungibilità del trasporto attraverso il tunnel e non dice nulla su TLS o sull’applicazione. Un controllo HTTP aggiunge un’attesa di stato e intercetta un listener che accetta connessioni ma non riesce a servire, che è il guasto più comune dopo un cambio di certificato o di backend. Nessuno dei due è una transazione aziendale autenticata se il test non autentica davvero, quindi non etichettatelo come tale sul pannello. Scegliete il controllo che fallisce quando si presenta il reclamo dell’utente.

ICMP è la più debole delle tre opzioni, dato che molti stack lo scartano per politica e un ping fallito dimostra molto poco.

Portate entrambi i segnali in Elastic senza inventarli

Il gateway VPN emette metriche di piattaforma come byte in uscita e in ingresso del tunnel e contatori di pacchetti scartati, e può inviare log diagnostici in categorie che includono eventi del tunnel e IKE. I risultati di Connection Monitor arrivano tramite Azure Monitor come metriche e tramite un’area di lavoro Log Analytics come record di log. Niente di tutto ciò compare da solo in un indice Elastic. Scegliete una pipeline supportata per le metriche e una per i log, di solito l’input Azure Event Hub o l’integrazione Azure Monitor, e verificate cosa l’integrazione installata ingerisce davvero prima di fidarvi dello schema dell’indice.

Conservate le etichette che permettono a un operatore di unire i due set di dati: endpoint sorgente, destinazione, protocollo e porta per la sonda, e identità del tunnel più indirizzo del peer per il gateway.

Validate la pipeline con un evento controllato, poi cercatelo in Elastic e controllate il timestamp e le etichette delle risorse. Un documento con il timestamp sbagliato è peggio di uno mancante, perché fa sembrare attuali dati obsoleti.

Avvisate sulla differenza, non sul colore

Il senso di tenere due segnali sono le combinazioni. Tunnel giù dovrebbe avvisare il responsabile di rete; tunnel su con sonda in errore il responsabile applicativo; un risultato di sonda mancante chi possiede l’agente di monitoraggio. Fondere tutti e tre in un unico pannello rosso garantisce che l’avviso venga silenziato entro un mese. Avvisate su un guasto persistente con una finestra di persistenza invece che su un singolo campione, e aggiungete un controllo separato per la salute della pipeline di ingestione stessa.

Un pannello pieno di campioni riusciti di ieri non dovrebbe leggersi come un percorso sano oggi.

Messo per iscritto, il contratto è piccolo: la metrica del tunnel dice che il gateway ha negoziato, la sonda dice che il percorso funziona da dove sono seduti gli utenti, e la salute della pipeline dice se una delle due risposte è attuale. Tutto il resto sul pannello è commento.