Perché il proxy di Cloudflare non può trasportare OpenVPN su un solo nome

Un’unica macchina esegue il sito web e il server OpenVPN, e la tentazione è puntare un solo nome host su di essa e lasciare che la nuvola arancione sistemi il traffico. Il proxy sistema HTTP e HTTPS. Non sistema una sessione OpenVPN, qualunque porta usi quella sessione. Due nomi, uno diretto e uno proxato, non costano nulla ed eliminano tutta questa classe di confusione.

Due nomi, due trasporti

Dai al sito web un record proxato così che il suo traffico HTTP e HTTPS passi da Cloudflare. Dai alla VPN un record solo DNS che risolva direttamente verso l’ingresso pubblico della VPN, e lascia che il client usi la porta UDP o TCP per cui è configurato.

Entrambi i nomi possono finire sulla stessa macchina di origine. La differenza è ciò che accade tra il client e quella macchina, e quella differenza è il senso della separazione.

Il riferimento alle porte di rete di Cloudflare elenca quali porte accetta il proxy web ordinario. Quell’elenco riguarda HTTP e HTTPS su quelle porte, non protocolli arbitrari che per caso condividono un numero.

La porta non è il protocollo

Spostare OpenVPN su TCP 443 non lo trasforma in HTTPS. Il proxy si aspetta ancora una richiesta HTTP all’inizio della connessione, e un client OpenVPN invia invece un messaggio di controllo binario. La connessione fallisce in un modo che sembra un blocco di rete perché nulla di utile arriva a un log.

Se il requisito è davvero mettere un prodotto Cloudflare nel percorso dati della VPN, valuta quello che documenta il supporto per il protocollo che ti serve. Non dare per scontato che la nuvola arancione sia un tunnel TCP o UDP generico, perché è un proxy inverso per il traffico web con un compito preciso.

Un record solo DNS è la risposta noiosa che funziona, ed è quella a cui ricorrere per prima.

Una macchina ha ancora bisogno di due listener

Nomi separati non permettono a due processi di legare lo stesso indirizzo, la stessa porta e lo stesso trasporto contemporaneamente. Se il server web occupa già TCP 443 su tutti gli indirizzi, un’istanza OpenVPN non può prenderlo anch’essa senza un accordo deliberato.

Lega il listener VPN a una porta diversa, o a un indirizzo diverso, oppure metti davanti un multiplexer documentato e accetta il costo operativo che comporta. Ognuna di queste scelte dovrebbe essere visibile nelle regole del firewall, perché un listener che nessuno ha documentato è quello che si trascura durante un incidente. Scrivi il binding scelto nello stesso runbook che descrive il tunnel. Così la persona successiva non lo riscoprirà alle due di notte.

I certificati seguono la connessione che proteggono

La connessione TLS del browser verso Cloudflare e la connessione di Cloudflare verso la tua origine sono due relazioni distinte con due certificati distinti. Il browser vede un certificato di bordo. L’origine presenta il proprio certificato a Cloudflare, e un certificato Cloudflare Origin CA è pensato esattamente per quella seconda relazione.

Quel certificato di origine è fidato da Cloudflare in modalità Full (strict) e non è un certificato browser fidato in generale. Se qualcuno visita direttamente il nome host solo DNS e riceve un avviso, è la conseguenza attesa di un percorso di fiducia cambiato, non la prova che la cifratura si sia fermata.

Un sito web visitato direttamente ha quindi bisogno di una catena di certificati di cui si fidano i suoi browser. Questo può convivere con un sito proxato la cui origine non è affatto destinata a essere visitata.

OpenVPN porta la propria identità di server e l’autenticazione del client, con la propria autorità di certificazione e la propria protezione del canale di controllo. Un lucchetto sul sito web non fornisce nulla di tutto ciò, e i due processi di approvvigionamento devono restare separati.

L’esposizione segue il nome

Un record VPN solo DNS pubblica l’indirizzo verso cui punta. Se quell’indirizzo è anche l’origine web, l’origine non è nascosta, e descriverla come nascosta perché l’altro nome è proxato è un errore che dura finché qualcuno non la scansiona.

Decidi quali richieste web possono raggiungere direttamente l’origine e applicalo all’origine, poi consenti il listener VPN alle sue condizioni. Le pagine di amministrazione, i download dei profili e il listener dati possono avere tre requisiti di esposizione diversi anche quando un solo pacchetto fornisce tutti e tre.

Mantieni i link generati sul nome web pubblico e sullo schema HTTPS, e mantieni i profili client sul nome della VPN con il protocollo e la porta reali. Nessuno dei due servizi dovrebbe dipendere dal cambio dell’impostazione proxy dell’altro durante il funzionamento normale.

Ordine di lavoro: nome proxato per il sito, nome solo DNS per la VPN, listener distinti, certificato per relazione, poi un test che dimostri che ogni nome raggiunge solo il servizio che deve.