Prefisso pubblico tramite OpenVPN: correggere il percorso di ritorno

Osservate il tunnel che sale e il client che fa ping dall’altra parte, poi un indirizzo pubblico che appartiene dietro la VPN risponde da un altro posto, o non risponde affatto. Di solito quel sintomo non ha nulla a che vedere con la cifratura o con i certificati. Un prefisso instradato dal fornitore viene consegnato come rotta IP, e portarlo attraverso OpenVPN significa riprodurre quella rotta su due livelli e preservare l’indirizzo di origine sul percorso di ritorno. Non serve fare bridging del WAN, e aggiungere l’indirizzo a un’interfaccia non crea la rotta a monte.

Il prefisso deve prima essere instradato verso di voi

Chiedete al fornitore come viene consegnato il blocco. Un prefisso instradato all’indirizzo principale del vostro server è cosa diversa dagli indirizzi che il fornitore si aspetta di raggiungere direttamente su un segmento WAN. Solo il primo modello funziona con il progetto qui.

Se il fornitore instrada 198.51.100.64/28 verso il vostro server di ingresso, i pacchetti per quell’intervallo arrivano al server e si fermano lì, a meno che non li inoltrini. Se invece il fornitore fa bridging dell’intervallo sul vostro uplink, il server deve rispondere ARP per esso, che è un altro problema.

Testate il modello di consegna prima di toccare OpenVPN: dall’esterno, fate ping a un indirizzo del blocco e osservate quale interfaccia lo riceve. Se non arriva nulla, nessuna configurazione del tunnel aiuterà. Se l’indirizzo risponde direttamente sul WAN, il fornitore fa bridging invece di instradare, e il progetto sotto non si applica.

Due livelli di instradamento: rotta del kernel e iroute

OpenVPN ha bisogno del prefisso in due punti. Il kernel deve sapere che il prefisso appartiene al dispositivo del tunnel, così i pacchetti inoltrati entrano in OpenVPN invece della rotta predefinita. OpenVPN deve anche sapere quale client autenticato possiede il prefisso, ed è la voce iroute nella directory specifica del client.

La rotta lato server appare così, con prefisso e maschera che corrispondono all’assegnazione:

ip route add 198.51.100.64/28 dev tun0

La configurazione specifica del client assegna la proprietà. Mettetela nel file CCD nominato secondo il nome comune del certificato client, e confermate che quella directory è quella che il server legge davvero:

iroute 198.51.100.64 255.255.255.240

La documentazione OpenVPN sulle reti instradate descrive entrambi i livelli e perché sono separati. Una rotta del kernel senza iroute invia pacchetti nel tunnel senza proprietario, e OpenVPN li scarta. Un iroute senza la rotta del kernel lascia i pacchetti sul percorso predefinito del server. Entrambi gli errori sembrano un tunnel rotto dal lato client.

Dove vive l’indirizzo del servizio

Il prefisso delegato non è la stessa cosa degli indirizzi propri del tunnel. Numerate il collegamento dallo spazio privato se volete, e collocate l’indirizzo pubblico del servizio dove il servizio gira davvero.

Su un client Linux che termina il servizio localmente, basta un singolo indirizzo host:

ip address add 198.51.100.70/32 dev lo

Se il prefisso viene instradato oltre verso un host VM o un’altra LAN, configurate invece quel percorso a valle e la sua rotta di ritorno. Assegnare ogni indirizzo del blocco al client VPN non è necessario e crea conflitti in seguito.

Mantenete l’origine pubblica sul percorso di ritorno

Una risposta dal prefisso delegato deve uscire dal tunnel e raggiungere la rotta del fornitore. Se l’host remoto la invia tramite il proprio ISP, l’indirizzo di origine sembra falsificato, e il fornitore o la destinazione la scartano. La soluzione è una regola basata sull’origine o una tabella di routing dedicata, non un NAT più ampio. Senza di essa, il servizio funziona dal peer del tunnel e fallisce da ogni altra parte.

Sul server di ingresso, un’ampia regola di masquerade è il colpevole abituale. Riscrive l’origine pubblica sull’indirizzo principale del server, e il client non vede mai quella vera:

iptables -t nat -S POSTROUTING

Limitate il NAT ai client VPN privati che ne hanno bisogno e lasciate il prefisso delegato non tradotto. Poi confermate che il server inoltri il prefisso, perché una catena di inoltro con rifiuto predefinito lo scarta in silenzio.

Verificate entrambe le direzioni prima di fidarvi

La verifica sono quattro osservazioni, non una. Confermate che arrivi la rotta del fornitore, che il kernel invii il prefisso nel tunnel, che OpenVPN lo attribuisca al client giusto e che la risposta torni con l’origine pubblica intatta. Ogni osservazione ha il proprio comando, quindi un guasto indica un livello e non l’intero progetto. Eseguitele in quest’ordine dopo ogni modifica di configurazione.

Chiedete al kernel quale percorso prende un indirizzo delegato, e osservate il tunnel mentre una richiesta è in corso:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Il filtraggio del percorso inverso può annullare una rotta corretta. Controllate l’impostazione effettiva sul tunnel e sull’uplink, e ricordate che la modalità strict rifiuta il traffico la cui origine non corrisponde all’interfaccia da cui è arrivato:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Infine, testate il caso di guasto. Fermate il tunnel e confermate che il prefisso pubblico non perda dal normale uplink. Ripristinare la VPN dovrebbe riportare il servizio senza ampliare quali porte l’host espone.