Enrutar el tráfico de VM en la red host-only a través de un servidor TUN OpenVPN

Los adaptadores host-only crean una red virtual local, y los túneles TUN enrutados transportan paquetes IP entre direcciones. Ninguno de los dos es un puente hacia el otro, por eso una configuración que funcione debe decir quién reenvía y a quién pertenece la ruta de vuelta. Si confundes esas dos asignaciones, el invitado responde al túnel con un origen que el cliente del túnel nunca pidió. El diseño de abajo mantiene ambos prefijos separados y hace explícita la ruta de vuelta.

Dos redes, dos prefijos

Da al pool del túnel y a la red host-only prefijos distintos y nunca reutilices uno para el otro. En este ejemplo el pool de VPN es 10.44.0.0/24 y la red host-only es 192.168.99.0/24, con el host en 192.168.99.1 y un invitado en 192.168.99.20. Asignar el mismo prefijo tanto a un dispositivo TUN como al adaptador host-only no los une. Crea dos reclamaciones sobre un mismo rango de direcciones, y la tabla de enrutamiento responde por la que resultó conservar.

El adaptador host-only existe en el host y dentro del invitado, y no tiene camino fuera de la máquina por sí solo. Las conexiones en puente y NAT tienen distinta exposición, y pasar a modo puente no es un requisito para llegar a un solo servicio del invitado.

El host ya tiene la ruta

Mira lo que existe antes de añadir nada. El host tiene una interfaz en la red host-only y una ruta para ese prefijo, ambas creadas cuando el adaptador subió.

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

La tercera línea es el mecanismo que convierte al host en un salto. Sin ella, un paquete que llega del túnel va dirigido a una red que el host puede alcanzar pero no reenviará. El reenvío es necesario y no suficiente. La política de filtrado sigue decidiendo si se permite un flujo concreto entre la interfaz del túnel y la interfaz host-only, y esa decisión debe estar por escrito en lugar de en una política por defecto que nadie leyó.

Empuja la ruta y luego filtra lo que alcanza

El servidor puede entregar el prefijo host-only a los clientes que aceptan rutas empujadas, que es el mismo mecanismo que se usa para cualquier otra subred detrás 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

Esas dos reglas permiten un servicio en una dirección y sus respuestas. Una ruta que alcanza todo el prefijo y un filtro que permite un solo puerto son una combinación deliberada; una ruta más una aceptación incondicional es como un servicio de laboratorio se convierte en un servicio expuesto. Una ruta empujada tampoco es una autorización. El cliente la acepta, el host la reenvía, y el cortafuegos del invitado y el propio servicio todavía tienen voto.

El invitado necesita un camino de vuelta

Un invitado al que se llega desde 10.44.0.x tiene que enviar sus respuestas a la dirección host-only del host, o el host tiene que traducir el origen. Recibir una dirección del DHCP de VirtualBox no dice nada sobre ninguna de las dos disposiciones.

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

Añadir esa ruta dentro del invitado conserva el origen original, lo que mantiene significativas la política y los registros por cliente. La traducción de origen limitada en el host es la alternativa, y funciona, a costa de ocultar qué cliente se conectó. El solapamiento es el otro modo de fallo. Un cliente remoto cuya LAN doméstica ya usa 192.168.99.0/24 leerá la ruta empujada como su propia red, y ningún cambio en el lado del servidor arregla esa ambigüedad. Renumera un lado o elige un prefijo que probablemente no colisione.

Un dispositivo TUN transporta paquetes IP, así que añadir una puerta de enlace por defecto dentro de un invitado no convierte el túnel en un segmento Ethernet con el adaptador host-only. El puente TAP es un diseño distinto con su propio soporte de clientes y propiedad de direcciones, y mezclar las dos descripciones lleva a configuraciones que nunca convergen.

Verifica y luego haz que sobreviva a un reinicio

Prueba un servicio inofensivo desde un cliente remoto corriente, comprueba la ruta de vuelta del invitado y confirma que un servicio que no permitiste se rechaza en lugar de ser lento.

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

Después reinicia el servicio de VPN y la red de la máquina virtual, y repite las mismas tres comprobaciones. Una ruta añadida a mano sobrevive hasta el siguiente reinicio, y una configuración que solo funciona en una sesión caliente no es un diseño. Anota los dos prefijos, la política de reenvío y la ruta del invitado juntos. Quien añada la siguiente máquina virtual necesitará las tres cosas y, si no, las redescubrirá una conexión fallida tras otra.