Un solo IP di servizio su ogni nodo OpenVPN: ciò che non fa

Un client si connette a uno di diversi server OpenVPN e poi ha bisogno di un piccolo servizio che gira su quel nodo: una pagina di stato, un endpoint delle metriche, un agente di backup. Dare a ogni nodo lo stesso indirizzo privato di servizio rende la configurazione del client identica indipendentemente dal server su cui è atterrato. Quella comodità è reale, ed è anche facile soprainterpretarla: l’indirizzo condiviso ti dice quale nodo hai raggiunto, non che qualcosa sia ridondante.

Perché lo stesso indirizzo su ogni nodo funziona

Ogni nodo possiede l’indirizzo localmente e risponde per esso, così un client che lo raggiunge attraverso il suo tunnel attuale ottiene il servizio all’altro capo di quel tunnel. Nulla viene coordinato tra i nodi, e nessun traffico passa da un nodo all’altro.

L’indirizzo è un’etichetta locale, ripetuta invece che replicata. Ogni nodo risponde solo per sé, e nessuno di loro inoltra traffico per l’indirizzo per conto di un altro nodo. È questo che mantiene valida una sola configurazione client mentre i server restano indipendenti. È anche il motivo per cui il progetto non richiede alcun coordinamento tra i nodi.

Ecco perché la stessa configurazione funziona su ogni server senza un protocollo di routing tra loro. È anche il motivo per cui il progetto non dice nulla sulla salute: l’indirizzo esiste su un nodo malato esattamente come su uno sano, perché è legato all’host e non al fatto che il servizio sia utile.

Assegnalo al loopback, non al tunnel

Mettere l’indirizzo su un’interfaccia di loopback lo disaccoppia dalla durata di qualsiasi dispositivo di tunnel, così una riconnessione o un ricaricamento della configurazione non lo rimuove. L’indirizzo esiste finché esiste l’host.

Un indirizzo su lo non è un filtro. Il servizio deve comunque ascoltare su di esso, e il firewall dell’host valuta ancora il percorso in ingresso reale, che arriva sull’interfaccia del tunnel. Chi presume che loopback significhi solo locale finisce per bloccare client legittimi o esporre qualcosa che non intendeva.

Rendi persistente l’assegnazione tramite la configurazione di rete dell’host invece di riaggiungerla da un hook. Un hook di installazione non scatta su un nodo dove non è salito alcun tunnel, e l’indirizzo di servizio non dovrebbe dipendere dall’attività del tunnel. Metti l’indirizzo nella configurazione dell’interfaccia gestita dalla tua distribuzione, poi riavvia una volta e controllalo. Un riavvio è l’unico test che sopravvive a un cambiamento di configurazione successivo.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Spingi una rotta e intendi una sola destinazione

Il client ha bisogno di una rotta host per l’indirizzo, offerta dal server a cui si connette. Poiché ogni server offre la stessa destinazione, il profilo non cambia quando il client si sposta.

Verifica cosa ha installato il client prima di dare la colpa al servizio.

ip route get 10.250.0.1

Per un servizio HTTP, dai all’indirizzo un nome e un certificato per quel nome. L’IP condiviso non è un’identità, e non elimina la verifica TLS, né giustifica la copia di una chiave privata su ogni nodo. Un nome che risolve all’indirizzo condiviso mantiene la storia del certificato ordinaria e ti consente di conservare un’identità per nodo se ti serve.

Ciò che l’indirizzo condiviso non può fare

Non fornisce failover. Se il nodo scelto muore, l’indirizzo muore con lui, e il client deve riconnettersi altrove.

Non migra una sessione TCP attiva, perché una nuova connessione termina su un host diverso che non sa nulla della vecchia.

Non sceglie un nodo sano, non bilancia il carico e non sincronizza i dati tra i nodi. Ognuno di questi è un meccanismo separato con i propri modi di guastarsi, e fingere che il trucco dell’indirizzamento li copra è il modo in cui un progetto semplice si guadagna una reputazione immeritata di resilienza. Se due tunnel sono attivi insieme, il significato della destinazione diventa ambiguo, quindi tieni esplicita l’ipotesi di un solo tunnel attivo.

Tieni l’identità del servizio insieme al nome

Scrivi cosa significa l’indirizzo: raggiunge il servizio sul nodo a cui il client è attualmente connesso. Quella singola frase previene la maggior parte dell’equivoco che questo schema attira.

Poi documenta i pezzi insieme: l’indirizzo, l’interfaccia su cui vive, la rotta che il server spinge, e il nome e il certificato che il servizio presenta. Quattro piccoli fatti che un lettore futuro può verificare, nell’ordine in cui li controllerà.

Se il requisito è una destinazione stabile per un servizio locale al nodo, lo schema si adatta e non costa quasi nulla.

Se il requisito è la disponibilità, sali di un livello: un bilanciatore di carico, un nome di servizio con controlli di salute, o un sistema di orchestrazione che sa già come sostituire un nodo.

Deciderlo presto mantiene l’indirizzo condiviso ciò che è, un’etichetta comoda, invece di un componente da cui ci si aspetta in silenzio un lavoro per cui non è mai stato progettato.