Instradare il traffico delle VM sulla rete host-only tramite un server TUN OpenVPN

Gli adattatori host-only creano una rete virtuale locale, e i tunnel TUN instradati trasportano pacchetti IP tra indirizzi. Nessuno dei due è un ponte verso l’altro, per questo una configurazione che funziona deve dire chi inoltra e a chi appartiene la rotta di ritorno. Se si scambiano queste due assegnazioni, l’ospite risponde al tunnel con una sorgente che il client del tunnel non ha mai chiesto. Il progetto qui sotto tiene separati entrambi i prefissi e rende esplicito il percorso di ritorno.

Due reti, due prefissi

Date al pool del tunnel e alla rete host-only prefissi diversi e non riutilizzate mai uno per l’altro. In questo esempio il pool VPN è 10.44.0.0/24 e la rete host-only è 192.168.99.0/24, con l’host su 192.168.99.1 e un ospite su 192.168.99.20. Assegnare lo stesso prefisso sia a un dispositivo TUN sia all’adattatore host-only non li unisce. Crea due rivendicazioni su un unico intervallo di indirizzi, e la tabella di routing risponde poi per quella che si è trovata a conservare.

L’adattatore host-only esiste sull’host e dentro l’ospite, e non ha un percorso fuori dalla macchina da solo. Le connessioni bridge e NAT hanno un’esposizione diversa, e passare alla modalità bridge non è un requisito per raggiungere un singolo servizio dell’ospite.

L’host possiede già il percorso

Guardate cosa esiste prima di aggiungere qualcosa. L’host ha un’interfaccia sulla rete host-only e una rotta per quel prefisso, entrambe create quando l’adattatore è salito.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

La terza riga è il meccanismo che trasforma l’host in un salto. Senza di essa, un pacchetto che arriva dal tunnel è indirizzato a una rete che l’host può raggiungere ma non inoltrerà. L’inoltro è necessario e non sufficiente. La politica di filtraggio decide ancora se un dato flusso tra l’interfaccia del tunnel e l’interfaccia host-only è consentito, e quella decisione va messa per iscritto invece che in una politica predefinita che nessuno ha letto.

Spingete la rotta, poi filtrate ciò che raggiunge

Il server può fornire il prefisso host-only ai client che accettano rotte spinte, che è lo stesso meccanismo usato per qualsiasi altra sottorete dietro il tunnel.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Queste due regole consentono un solo servizio in una direzione e le sue risposte. Una rotta che raggiunge l’intero prefisso e un filtro che consente una sola porta sono una combinazione deliberata; una rotta più un’accettazione incondizionata è il modo in cui un servizio di laboratorio diventa un servizio esposto. Una rotta spinta non è nemmeno un’autorizzazione. Il client la accetta, l’host la inoltra, e il firewall dell’ospite e il servizio stesso hanno ancora voce in capitolo.

L’ospite ha bisogno di un percorso di ritorno

Un ospite raggiunto da 10.44.0.x deve inviare le sue risposte all’indirizzo host-only dell’host, oppure l’host deve tradurre la sorgente. Ricevere un indirizzo dal DHCP di VirtualBox non dice nulla su nessuna delle due disposizioni.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Aggiungere quella rotta dentro l’ospite conserva la sorgente originale, il che mantiene significative la politica e i registri per client. La traduzione di sorgente limitata sull’host è l’alternativa, e funziona, al prezzo di nascondere quale client si è connesso. La sovrapposizione è l’altro modo di fallire. Un client remoto la cui LAN domestica usa già 192.168.99.0/24 leggerà la rotta spinta come la propria rete, e nessuna modifica lato server risolve quell’ambiguità. Rinumerate un lato o scegliete un prefisso che difficilmente entrerà in collisione.

Un dispositivo TUN trasporta pacchetti IP, quindi aggiungere un gateway predefinito dentro un ospite non trasforma il tunnel in un segmento Ethernet con l’adattatore host-only. Il bridge TAP è un progetto diverso con il proprio supporto client e la propria proprietà degli indirizzi, e mescolare le due descrizioni porta a configurazioni che non convergono mai.

Verificate, poi fate in modo che sopravviva a un riavvio

Provate un servizio innocuo da un normale client remoto, controllate la rotta di ritorno dell’ospite e confermate che un servizio che non avete permesso viene rifiutato anziché essere lento.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Poi riavviate il servizio VPN e la rete della macchina virtuale, e ripetete gli stessi tre controlli. Una rotta aggiunta a mano sopravvive fino al riavvio successivo, e una configurazione che funziona solo in una sessione calda non è un progetto. Annotate insieme i due prefissi, la politica di inoltro e la rotta dell’ospite. Chi aggiungerà la prossima macchina virtuale avrà bisogno di tutte e tre e, altrimenti, le riscoprirà una connessione fallita dopo l’altra.