Puerta de enlace VPN de VirtualBox para la LAN: puente, ruta y retorno

Los usuarios remotos necesitan llegar a una impresora y a un servidor de archivos en una LAN física, y el único equipo Linux siempre encendido es una VM de VirtualBox. Puentear la VM en esa LAN es la primera mitad. La segunda mitad es una ruta de retorno que cada dispositivo de la LAN usará de verdad, y esa es la parte que la mayoría de las instalaciones pasa por alto. Cuando falta, el túnel se conecta, el cliente hace ping a la puerta de enlace y nada más responde.

Use direcciones que se puedan alcanzar

Ponga el adaptador de LAN de la VM en la conexión Bridged Adapter aprobada para esa red y asígnele una dirección mediante el proceso normal de asignación. Entonces la VM aparece en la LAN física como cualquier otro host. Su ruta predeterminada debe seguir usando la puerta de enlace real, para que el transporte cifrado hasta el par VPN siga siendo alcanzable. No use la dirección NAT predeterminada de VirtualBox como siguiente salto de la LAN, porque esa dirección vive detrás de un NAT virtual y no está on-link para el host ni para las demás máquinas de la 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

Compruebe si hay solapamiento con las redes domésticas de los usuarios remotos antes de elegir el grupo de direcciones. El solapamiento se convierte en una ambigüedad de enrutamiento que ninguna configuración del servidor corrige.

Anuncie la LAN y luego reenvíe

Para un servidor cuya autenticación y transporte ya se gestionan, las líneas de red son estas. El push le dice al cliente que acepta cómo llegar a la LAN, y por sí solo no hace que la VM reenvíe nada.

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

Active el reenvío IPv4 en la configuración de red persistente de la VM y permita que el grupo de clientes llegue a los servicios de LAN previstos en el límite de reenvío de la VM. El permiso para llegar al escucha VPN es una regla aparte, y ya funciona si el túnel se levantó.

La ruta de retorno va en el router de la LAN

Los dispositivos de la LAN responden por su puerta de enlace predeterminada, que es el router de la LAN en 192.168.70.1. Ese router no tiene idea de dónde vive 10.80.0.0/24 si no se lo dicen. Añada la ruta del grupo a la configuración persistente admitida del router, apuntando a la dirección de LAN de la VM. Añadirla solo en el host de VirtualBox repara los caminos que consultan ese host, que no es cada dispositivo de la LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

El cortafuegos del destino todavía tiene que permitir el grupo de clientes como origen. Una ruta lleva el paquete; no concede el servicio.

Si el router de la LAN no se puede cambiar, la alternativa es la traducción de origen limitada en la VM. Hace que las respuestas vuelvan sin la ruta y oculta las direcciones individuales de los clientes al servicio de la LAN.

Siga un paquete de extremo a extremo

Un cliente en 10.80.0.25 envía a 192.168.70.40 por el túnel. La VM reenvía el paquete a la LAN. El servicio responde a su router, que elige la VM para el grupo de clientes, y la VM devuelve el paquete por OpenVPN. Cada salto de esa frase es un lugar donde el diseño puede fallar.

Pruebe con la aplicación real desde un cliente remoto y repita después de recargar la configuración gestionada tanto en la VM como en el router.

Si el cliente llega a la VM pero no al servicio, revise primero la ruta del router. Si el servicio recibe la petición y el cliente nunca ve la respuesta, el camino de retorno es el sospechoso.