Monitoraggio distribuito: Collegamento dei siti remoti in Checkmk

Il monitoraggio distribuito con Checkmk consiste in un'istanza centrale e almeno un sito remoto. La struttura di questo tipo di monitoraggio distribuito, in particolare la connessione dei siti remoti, è essenzialmente una procedura di rete standard. Tuttavia, è necessario tenere conto anche delle caratteristiche di Checkmk.

In questo articolo, a scopo dimostrativo, lavorerò con una semplice configurazione di un monitoraggio distribuito, costituito da un'istanza centrale e da diversi siti remoti, inclusa la sincronizzazione della configurazione. Inoltre, in queste best practice per la connessione di siti remoti, ci limitiamo a IPv4, poiché l'esperienza dimostra che attualmente le organizzazioni gestiscono una intranet IPv4 pura o una intranet dual-stack con IPv4 e IPv6, ma non una intranet IPv6 pura.

L'esempio più semplice è quello di una rete piatta in cui il routing funziona tra gli host che gestiscono i siti Checkmk. Questa è la configurazione più tipica di una piccola organizzazione senza filiali, per cui il monitoraggio distribuito non è sempre necessario.

Le aziende con filiali operano in genere una VPN a livello aziendale, che di solito è almeno orchestrata da un IT centrale. Ciò significa che assegna una subnet esclusiva alle singole sedi, che a sua volta consente un semplice instradamento. Il monitoraggio distribuito non è strettamente necessario in una rete di questo tipo. Se le filiali hanno pochi dispositivi (regola empirica: numero a una cifra di dispositivi) o provvedono alla gestione senza un hypervisor, di solito non vengono utilizzati siti remoti.

Site2Site-VPN

Con un managed service provider, le cose sono ancora diverse. In questo caso, di solito ci sono diverse connessioni alle reti dei clienti. Un tipo di connessione tipico è la VPN Site2Site, che arriva a un firewall dedicato per le connessioni del cliente. Un problema comune in questo caso è che le reti dei clienti utilizzano intervalli IPv4 privati che si sovrappongono. Di conseguenza, il routing diretto in queste reti private non è generalmente possibile. In alternativa, qui può essere utilizzato il NAT (Network Address Translation).

Un altro tipo di connessione tipica è il DNAT (Destination Network Address Translation) sul firewall del cliente, ossia senza una connessione VPN al cliente. In questo caso, le porte alte dedicate sul firewall del cliente vengono inoltrate all'host del sito remoto. Gli IP di origine sono limitati alla rete più piccola possibile dell'MSP; sono necessarie solo le connessioni in entrata. In pratica, la situazione può essere la seguente:

In questo esempio, le porte alte del firewall sono impostate nell'intervallo ID 655x, tipico di Checkmk. L'ultima cifra corrisponde al tipo di connessione (vedi elenco precedente).

Il grande vantaggio di questa variante è che le sovrapposizioni delle reti dei clienti non contano, il che consente a un fornitore di servizi di realizzare installazioni intranet standardizzate.

L'host del sito remoto deve essere interrogato in modo sufficientemente dettagliato come host di stato, anche se la configurazione di un host di stato nelle impostazioni del sito può essere evitata quando si utilizza il live proxy. A tal fine, è necessario eseguire il tunnel dell'uscita dell'agente tramite SSH, come nell'esempio, e quindi rinunciare a un'altra connessione DNAT. Il comando di controllo dell'host deve quindi essere modificato in base allo stato del servizio Checkmk.

La connessione opzionale per le notifiche viene utilizzata per elaborare le notifiche a livello centrale, ad esempio in un sistema di ticket centrale dell'MSP. Attualmente Checkmk non fornisce una soluzione di crittografia in questo caso, e questo non cambierà fino alla prossima versione (Checkmk 2.1). Nel frattempo, tuttavia, Stunnel, ad esempio, potrebbe essere una soluzione.

DNAT per un robusto monitoraggio MSP

Per un solido ed eterogeneo monitoraggio MSP, è consigliabile utilizzare il DNAT come standard. Se i singoli clienti insistono sulla VPN con reti clienti incompatibili, sono possibili soluzioni che includono anche host intermedi. In questo caso, l'host intermedio, che si trova nel data center del fornitore, può comunicare tramite VPN con l'host del sito remoto presso la sede del cliente. L'host intermedio offre questa connessione all'istanza centrale tramite port forwarding.

Gli approcci discussi finora presuppongono sempre che l'accesso da un intervallo di indirizzi dell'MSP, avviato dall'istanza Checkmk centrale, sia possibile e consentito. Tuttavia, per motivi di sicurezza, in alcuni casi ciò potrebbe non essere auspicabile. Il metodo CMCDump è adatto a questa casistica, che a propria volta comporta delle restrizioni.

Con questo metodo, un cron job crea un archivio dello stato generale corrente a un intervallo di tempo specificato, ad esempio ogni minuto. Questo file di archivio creato viene poi trasmesso all'istanza centrale e importato. Un prerequisito per CMCDump, tuttavia, è che il traffico in uscita sia consentito e che sia anche adatto al trasporto del file di archivio, ad esempio un .tgz. Il trasferimento può avvenire tramite scp a un host di file o via e-mail. Tuttavia, la soluzione di trasporto individuale deve essere gestita da script.

Si può affermare che, a seconda delle condizioni quadro, sono possibili soluzioni di qualsiasi complessità richiesta. A questo punto, ai managed service provider si consiglia di definire in anticipo le possibili varianti di implementazione e i requisiti necessari, e di documentarle e comunicarle adeguatamente per evitare di creare lavoro extra per il cliente.