Gateway VPN VirtualBox per la LAN: bridge, rotta, ritorno

Collegate in bridge la VM gateway alla LAN, annunciate la LAN ai client e aggiungete la rotta del pool al router della LAN. Un esempio IPv4 svolto con percorsi di ritorno reali.

Gli utenti remoti devono raggiungere una stampante e un file server su una LAN fisica, e l’unica macchina Linux sempre accesa è una VM VirtualBox. Collegare la VM a quella LAN in bridge è la prima metà. La seconda metà è una rotta di ritorno che ogni dispositivo della LAN userà davvero, ed è la parte che quasi tutte le configurazioni dimenticano. Quando manca, il tunnel si connette, il client fa ping al gateway e nient’altro risponde.

Usate indirizzi raggiungibili

Impostate l’adattatore LAN della VM sulla modalità Bridged Adapter approvata per quella rete e assegnategli un indirizzo con il normale processo di allocazione. La VM appare allora sulla LAN fisica come qualsiasi altro host. La sua rotta predefinita deve continuare a usare il gateway reale, così il trasporto cifrato verso il peer VPN resta raggiungibile. Non usate l’indirizzo NAT predefinito di VirtualBox come salto successivo per la LAN, perché quell’indirizzo vive dietro un NAT virtuale e non è on-link per l’host né per le altre macchine della LAN.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

Controllate la sovrapposizione con le reti domestiche degli utenti remoti prima di scegliere il pool. Una sovrapposizione diventa un’ambiguità di routing che nessuna configurazione del server corregge.

Annunciate la LAN, poi inoltrate

Per un server la cui autenticazione e il cui trasporto sono già gestiti, le righe di rete sono queste. Il push dice al client che accetta come raggiungere la LAN, e da solo non fa inoltrare nulla alla VM.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

Attivate l’inoltro IPv4 nella configurazione di rete persistente della VM e consentite al pool di client di raggiungere i servizi LAN previsti al confine di inoltro della VM. Il permesso di raggiungere il listener VPN è una regola separata, e funziona già se il tunnel è salito.

La rotta di ritorno sta sul router della LAN

I dispositivi della LAN rispondono tramite il loro gateway predefinito, cioè il router della LAN a 192.168.70.1. Quel router non ha idea di dove si trovi 10.80.0.0/24 se non glielo si dice. Aggiungete la rotta del pool alla configurazione persistente supportata del router, puntando all’indirizzo LAN della VM. Aggiungerla solo sull’host VirtualBox ripara i percorsi che interrogano quell’host, e non è ogni dispositivo della LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Il firewall della destinazione deve comunque consentire il pool di client come sorgente. Una rotta trasporta il pacchetto; non concede il servizio.

Se il router della LAN non può essere modificato, l’alternativa è la traduzione di sorgente limitata sulla VM. Fa tornare le risposte senza la rotta e nasconde gli indirizzi individuali dei client al servizio della LAN.

Seguite un pacchetto da un capo all’altro

Un client a 10.80.0.25 invia verso 192.168.70.40 attraverso il tunnel. La VM inoltra il pacchetto sulla LAN. Il servizio risponde al suo router, che sceglie la VM per il pool di client, e la VM restituisce il pacchetto tramite OpenVPN. Ogni salto di quella frase è un punto in cui il progetto può fallire.

Provate con l’applicazione reale da un client remoto, poi ripetete dopo aver ricaricato la configurazione gestita sia sulla VM sia sul router.

Se il client raggiunge la VM ma non il servizio, controllate prima la rotta del router. Se il servizio riceve la richiesta e il client non vede mai la risposta, il percorso di ritorno è il sospetto.

Articoli correlati