Instradare i client OpenVPN tramite Cloudflare? Controllate prima il ruolo

Avete un server OpenVPN funzionante e un host che esegue anche il software per dispositivi di Cloudflare, e il prossimo passo ovvio sembra indirizzare il traffico dei client verso di esso. Due connessioni funzionanti su una macchina non formano un gateway di transito. Ciò che manca è un ruolo documentato per inoltrare pacchetti appartenenti a qualcun altro, e una policy che classifichi quei pacchetti quando arrivano.

Prima di ogni regola ci sono quattro domande: quale traffico entra, dove va dopo, come le risposte trovano la via di ritorno e cosa fa il progetto quando quel secondo percorso fallisce. Le prime due sono domande di capacità.

Due servizi su un solo host non sono un percorso di transito

Un client per dispositivo è costruito per gestire il traffico che ha origine sulla macchina dove viene eseguito. Intercetta la risoluzione dei nomi, o traffico applicativo selezionato, e lo invia nel proprio tunnel, e la sua policy è scritta per l’utente di quel dispositivo e per i processi di quel dispositivo. Un pacchetto inoltrato da un client OpenVPN non è output locale, quindi le stesse regole non lo classificano. Non è un dettaglio di configurazione che si possa coprire con una regola più ampia, perché decide se il software vede il pacchetto.

Per questo la domanda di progetto è una domanda di capacità. O il prodotto installato ha un ruolo documentato che inoltra traffico per altre reti, oppure la funzione di transito appartiene a un luogo del tutto diverso.

Quale ruolo di Cloudflare può inoltrare

Il client per dispositivi di Cloudflare offre modalità che differiscono per portata: solo risoluzione dei nomi, traffico dal dispositivo e talvolta entrambe. Nessuna di queste modalità trasforma l’host in un router per un intervallo privato che arriva da un altro tunnel. Il ruolo di routing dedicato è un prodotto separato con il proprio connettore, registrazione e modello di rete.

Controllate il ruolo installato prima di progettare route attorno ad esso. Leggete quale interfaccia crea il connettore, se annuncia prefissi specifici o una route predefinita, e se la policy locale si applica ai pacchetti inoltrati oltre che a quelli locali. Se viene gestito solo il traffico locale, il server OpenVPN non può essere il punto di transito, comunque sia scritta la regola di traduzione.

Qui va anche formulato con precisione il requisito di uscita pubblica. Un’uscita fornita da Cloudflare per il traffico dei client inoltrato è un caso d’uso specifico, e va confermata rispetto al servizio che avete realmente.

Mantenete il tunnel esterno indipendente dalla nuova route

Nel momento in cui aggiungete una route predefinita verso la nuova interfaccia, il traffico in uscita del server inizia a contendersela, e questo include le risposte ai client OpenVPN e la vostra sessione SSH verso la macchina. Il sintomo abituale è un tunnel che si stabilisce e poi muore, o un amministratore chiuso fuori mentre la modifica sembra aver funzionato. Confrontate ip route get per l’endpoint prima e dopo, e usate il routing basato su policy o una route host per mantenere il trasporto proprio del server dov’era. Eseguite quel confronto dalla macchina stessa, perché è la visione del server sulla propria route che conta.

Un’eccezione per l’indirizzo pubblico del server non basta da sola, perché il percorso di ritorno di ogni amministratore remoto è un flusso diverso. Decidete quali di questi flussi devono sopravvivere alla modifica, poi verificate ciascuno invece di supporre che il primo copra gli altri.

Limitate l’inoltro e la traduzione a un solo flusso

I pacchetti ricevuti seguono il percorso di inoltro, non quello di output locale, quindi la regola che conta vive nell’hook forward. Dove l’interfaccia successiva necessita di traduzione, limitate la sorgente al pool dei client, la destinazione a ciò che è consentito e l’uscita a quella singola interfaccia. Una regola masquerade legata solo a un’interfaccia non sceglie alcuna route da sola e non consente l’inoltro oltre qualsiasi altro filtro.

Decidete in anticipo il comportamento di chiusura in caso di errore, poi provatelo. Fermate il percorso successivo e confermate che i client perdono l’uscita prevista invece di ricadere in silenzio sull’uplink ordinario, perché è il risultato che nessuno nota finché il traffico non esce dalla porta sbagliata. Ripetete il controllo per la risoluzione dei nomi e per IPv6, perché un insieme di regole solo per v4 lascia aperto un percorso v6.

Annotate le quattro risposte su cui vi siete fermati e l’osservazione che dimostra ciascuna. Un percorso di transito che sapete descrivere è uno che sapete difendere alla prossima revisione degli incidenti.