OpenVPN: l’indirizzo locale contro l’indirizzo del tunnel: due socket diversi

Il client rifiuta di partire e si lamenta che non riesce a collegare un indirizzo locale, e la correzione ovvia sembra puntarlo all’indirizzo del tunnel che si aspetta di ricevere. Non può funzionare, e la ragione merita di essere capita: prima che il tunnel esista non c’è alcun indirizzo interno, e il socket che contatta il server deve esistere prima. Ci sono due indirizzi diversi in gioco, e solo uno dei due può essere scelto localmente.

L’errore di bind nomina un indirizzo locale

Quando OpenVPN segnala che non riesce a collegare un indirizzo locale, parla del socket di trasporto: l’estremità UDP o TCP che porta la connessione cifrata verso il peer.

Una direttiva local esplicita chiede al demone di collegare quel socket a un indirizzo locale preciso. L’indirizzo deve esistere nello spazio dei nomi di rete in cui gira il processo, e deve essere assegnabile nel momento in cui il client parte.

Un indirizzo pubblico tradotto su un router o al bordo del cloud non è un indirizzo locale che il demone possa collegare, anche se è l’indirizzo che vede il server. Questa distinzione spiega perché un profilo funziona a casa e fallisce su un’istanza cloud. Spiega anche perché aggiungere l’indirizzo pubblico a un’interfaccia loopback non aiuta, dato che il trasporto partirebbe da un indirizzo a cui la rete non può rispondere. Leggi l’elenco delle interfacce prima di modificare il profilo.

Che cosa selezionano davvero local e remote

remote nomina il peer da contattare. local collega l’estremità vicina dello stesso socket. nobind lascia che il sistema operativo scelga sia l’indirizzo locale sia la porta, ed è per questo che i client dietro i router domestici di solito funzionano senza nessuna delle due direttive.

Nessuna delle due direttive ha niente a che vedere con l’indirizzo dentro il tunnel.

In un container o in uno spazio dei nomi di rete vale la stessa regola con confini più stretti: gli indirizzi dell’host non sono presenti all’interno, quindi una riga local copiata dalla configurazione dell’host fallisce per un motivo del tutto diverso da un indirizzo sbagliato.

ip -brief address show
ip route get 203.0.113.10

L’indirizzo interno arriva dal server

L’indirizzo dentro il tunnel viene negoziato o assegnato dopo che il canale di controllo è stabilito. Con un pool dinamico lo decide il server al momento della connessione, e con una configurazione specifica del client può essere fisso per identità.

Scrivere local con un indirizzo interno non chiede al server di assegnare quell’indirizzo. Nel migliore dei casi il bind fallisce; nel peggiore il client trova un indirizzo host non correlato con lo stesso valore e comincia a usarlo per il trasporto.

Anche le interfacce da leggere sono diverse. I parametri di ifconfig e la configurazione del pool descrivono l’interno, mentre remote, local, proto e nobind descrivono l’esterno. Tenere separate le due liste spiega quasi ogni esempio confuso che troverai su un forum. Il manuale di OpenVPN 2.6 li documenta in sezioni separate proprio per questo motivo.

La trappola: un tunnel completo che cattura il proprio trasporto

Una volta che il tunnel è attivo e porta la rotta predefinita, i pacchetti che lo sostengono non devono essere instradati al suo interno. È un problema di instradamento e non di indirizzamento, e il demone lo risolve installando una rotta più specifica verso l’indirizzo del server stesso attraverso il gateway originale.

Se fissi il trasporto a un indirizzo locale preciso e poi cambi il percorso che quell’indirizzo usa, la connessione esterna può perdersi mentre l’interno resta configurato. Il tunnel continua a segnalare di essere connesso perché l’interno è a posto. Solo il trasporto è rotto, ed è per questo che i log si leggono come contraddizioni.

I sintomi allora somigliano a un tunnel che si connette e si blocca, o a uno che si riconnette in ciclo senza un errore utile. Controlla la rotta verso l’indirizzo del peer prima di controllare qualcosa dentro il tunnel, e conferma che l’indirizzo locale collegato appartenga ancora all’interfaccia che ti aspettavi.

Un’abitudine che evita la confusione

Leggi ogni indirizzo di un profilo e decidi a quale strato appartiene prima di modificarlo.

Se nomina l’estremità remota del trasporto o ne collega l’estremità vicina, è un indirizzo esterno e deve esistere prima dell’avvio. Se descrive ciò che accade dentro il tunnel, viene dal server o dalla topologia, e nessuna direttiva locale può sostituirlo.

Scrivi le due liste nelle note di distribuzione accanto al profilo. La prossima sessione di diagnostica comincerà allora dallo strato invece che da una supposizione.