Encaminar el trànsit de VM a la xarxa host-only a través d'un servidor TUN OpenVPN

Els adaptadors host-only creen una xarxa virtual local, i els túnels TUN encaminats porten paquets IP entre adreces. Cap dels dos no és un pont cap a l'altre, i per això una configuració que funcioni ha de dir qui reenvia i a qui pertany la ruta de tornada. Si equivoqueu aquestes dues assignacions, el convidat respon al túnel amb una origen que el client del túnel mai no ha demanat. El disseny de sota manté els dos prefixos separats i fa explícit el camí de tornada.

Dues xarxes, dos prefixos

Doneu al pool del túnel i a la xarxa host-only prefixos diferents i no reutilitzeu mai l'un per a l'altre. En aquest exemple el pool de VPN és 10.44.0.0/24 i la xarxa host-only és 192.168.99.0/24, amb l'amfitrió a 192.168.99.1 i un convidat a 192.168.99.20. Assignar el mateix prefix tant a un dispositiu TUN com a l'adaptador host-only no els uneix. Crea dues reclamacions sobre un mateix rang d'adreces, i la taula d'encaminament respon per la que ha resultat que conservava.

L'adaptador host-only existeix a l'amfitrió i dins del convidat, i no té cap camí fora de la màquina per si sol. Les connexions en pont i NAT tenen una exposició diferent, i passar a mode pont no és un requisit per arribar a un sol servei del convidat.

L'amfitrió ja té el camí

Mireu què hi ha abans d'afegir res. L'amfitrió té una interfície a la xarxa host-only i una ruta per a aquest prefix, totes dues creades quan l'adaptador es va aixecar.

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

La tercera línia és el mecanisme que converteix l'amfitrió en un salt. Sense això, un paquet que arriba del túnel s'adreça a una xarxa que l'amfitrió pot assolir però no reenviarà. El reenviament és necessari i no suficient. La política de filtratge encara decideix si es permet un flux concret entre la interfície del túnel i la interfície host-only, i aquesta decisió ha de ser per escrit i no en una política per defecte que ningú no ha llegit.

Empenyeu la ruta i després filtreu què assoleix

El servidor pot subministrar el prefix host-only als clients que accepten rutes empenyudes, que és el mateix mecanisme que s'utilitza per a qualsevol altra subxarxa darrere del túnel.

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

Aquestes dues regles permeten un sol servei en una direcció i les seves respostes. Una ruta que arriba a tot el prefix i un filtre que permet un sol port són una combinació deliberada; una ruta més una acceptació incondicional és com un servei de laboratori es converteix en un servei exposat. Una ruta empenyuda tampoc no és cap autorització. El client l'accepta, l'amfitrió la reenvia, i el tallafoc del convidat i el propi servei encara hi tenen vot.

El convidat necessita un camí de tornada

Un convidat a què s'arriba des de 10.44.0.x ha d'enviar les seves respostes a l'adreça host-only de l'amfitrió, o l'amfitrió ha de traduir l'origen. Rebre una adreça del DHCP de VirtualBox no diu res sobre cap de les dues disposicions.

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

Afegir aquesta ruta dins del convidat conserva l'origen original, cosa que manté significatives la política i els registres per client. La traducció d'origen limitada a l'amfitrió és l'alternativa, i funciona, a costa d'amagar quin client s'ha connectat. El solapament és l'altre mode de fallada. Un client remot la LAN del qual ja utilitza 192.168.99.0/24 llegirà la ruta empenyuda com la seva pròpia xarxa, i cap canvi al costat del servidor no arregla aquesta ambigüitat. Renombreu un costat o trieu un prefix que probablement no col·lideixi.

Un dispositiu TUN porta paquets IP, així que afegir una porta d'enllaç per defecte dins d'un convidat no converteix el túnel en un segment Ethernet amb l'adaptador host-only. El pont TAP és un disseny diferent amb el seu propi suport de clients i propietat d'adreces, i barrejar les dues descripcions porta a configuracions que no convergeixen mai.

Verifiqueu-ho i feu que sobrevisqui a un reinici

Proveu un servei inofensiu des d'un client remot ordinari, comproveu la ruta de tornada del convidat i confirmeu que un servei que no heu permès es rebutja en lloc de ser lent.

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

Després reinicieu el servei de VPN i la xarxa de la màquina virtual, i repetiu les mateixes tres comprovacions. Una ruta afegida a mà sobreviu fins al següent reinici, i una configuració que només funciona en una sessió calenta no és un disseny. Anoteu els dos prefixos, la política de reenviament i la ruta del convidat junts. Qui afegeixi la propera màquina virtual necessitarà les tres coses i, si no, les redescobrirà una connexió fallida rere l'altra.