Laboratorio VPN con VirtualBox: VM de puerta de enlace o red solo para el anfitrión

Debe decidir cuánta maquinaria merece su laboratorio VPN. Una VM de puerta de enlace enrutada entre dos segmentos de VirtualBox reproduce la traducción de direcciones, la ruta de retorno y la posición del cortafuegos detrás de la cual se sienta un cliente real. Un único segmento solo para el anfitrión le da una puerta controlada y nada más. La versión con puerta de enlace cuesta tres invitados y una tabla de enrutamiento que usted mantiene; la versión solo para el anfitrión cuesta un invitado y una política. Tres preguntas las separan, y la tercera decide si su prueba puede aprobar siquiera.

Responda tres preguntas antes de clonar nada

Empiece por lo que el servidor VPN tiene que observar. Si el servidor debe ver una dirección de origen que no es la del invitado de prueba, algo tiene que traducir entre ambos, y ese algo tiene que ser un enrutador que usted controle. La red solo para el anfitrión le da al anfitrión un adaptador en el segmento del invitado, no un traductor. Cuando el invitado necesita alcanzar algo exterior, conecta un adaptador NAT, y el propio motor NAT de VirtualBox reescribe el origen sin preguntarle.

Después pregunte si el invitado puede alcanzar algo excepto a través del túnel. Esa respuesta elige interno o solo para el anfitrión, y es la pregunta que la mayoría de las descripciones de laboratorio omiten. Por último, pregunte qué debe ocurrir cuando el túnel cae, porque eso decide la política y no la topología, y un laboratorio que solo demuestra el camino feliz no ha probado casi nada.

Conecte los tres papeles con redes internas

Use tres invitados y dos segmentos con nombre, con la puerta de enlace como la única máquina que tiene un adaptador en ambos:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

No hay un paso de creación aparte para una red interna. La cadena de --intnet1 es el segmento: dos máquinas lo comparten solo si el nombre coincide exactamente, y nada del anfitrión está conectado a él. Esa última propiedad es la razón por la que el laboratorio se repite limpiamente, ya que las rutas del anfitrión, su propio cliente VPN y su cortafuegos no pueden alcanzar a los invitados por accidente. Un segmento interno tampoco tiene servidor DHCP a menos que añada uno, así que las direcciones estáticas son el camino más corto.

Dé al cliente solo su dirección WAN, con una puerta de enlace predeterminada que apunte a la dirección WAN de la puerta de enlace. El servidor recibe una dirección LAN y usa la dirección LAN de la puerta de enlace como su puerta de enlace predeterminada. Un invitado que mantiene dos direcciones en un segmento, o una ruta perdida hacia el otro segmento, tiene un camino alrededor del enrutador, y las pruebas de abajo le mentirán.

Tengo un archivo de texto junto a los nombres de las VM con las cuatro direcciones y los dos nombres de segmento, y lo pego en cada shell. Semanas después, cuando un cambio de perfil rompe algo, ese archivo es la diferencia entre depurar el perfil y depurar mi propia memoria.

Elija interno o solo para el anfitrión para el segmento que no debe filtrarse

El modo solo para el anfitrión crea un adaptador virtual en el propio anfitrión, normalmente vboxnet0, y le da al anfitrión una dirección en el segmento del invitado. Eso es cómodo para la administración y fatal para una prueba de aislamiento, porque el anfitrión ahora puede alcanzar al invitado directamente y cada servicio del lado del anfitrión se convierte en un camino posible. El modo interno no tiene ningún adaptador de anfitrión. Los dos modos se confunden fácilmente en el panel de configuración de red, así que compruebe la diferencia documentada en lugar de la etiqueta (vea la página detalles de red de VirtualBox).

Para un invitado que debe usar el túnel, el interno es el valor predeterminado más seguro, con la puerta de enlace como única salida. Si mantiene solo para el anfitrión, trate el adaptador del anfitrión como un camino de gestión y dígalo en voz alta: el anfitrión puede alcanzar al invitado, y el invitado no debe poder usar el anfitrión como salida.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

El aislamiento que puede demostrar es el aislamiento que ha configurado. Un invitado con un adaptador interno, una ruta predeterminada en la puerta de enlace y ningún adaptador NAT no tiene ningún camino que evite la puerta de enlace. Un invitado con un adaptador solo para el anfitrión y un adaptador NAT tiene dos caminos, y solo uno de ellos es el que quería probar.

Enrute y traduzca en la puerta de enlace, y luego haga que falle cerrada

VirtualBox no reenvía entre segmentos; lo hace el invitado. Con la VM del servidor VPN detrás de la puerta de enlace, active el reenvío y traduzca el tráfico del cliente mientras sale hacia el servidor:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Con esa regla el servidor ve la dirección LAN de la puerta de enlace en lugar de la del cliente, que es como se ve un cliente real detrás de un NAT de operador desde una cabecera de red. Guarde el valor de sysctl en /etc/sysctl.d/ y la regla en el servicio de cortafuegos que use la distribución, o un reinicio devolverá el laboratorio en silencio a un estado enrutado pero no traducido.

El reenvío no es autorización. Bajo la política FORWARD predeterminada de ACCEPT, un invitado cuya ruta predeterminada apunta a la puerta de enlace sale por la interfaz que elija la tabla de enrutamiento, con túnel o sin él. Si la puerta de enlace también tiene un adaptador NAT para instalar paquetes, ese adaptador es una salida sin cifrar que funciona en el momento en que cae el túnel, y su prueba solo-VPN nunca fue una prueba solo-VPN.

Cuando el servidor es remoto y es la puerta de enlace la que termina el túnel, la misma decisión apunta a la interfaz del túnel, no a la NIC que llega a internet:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Mantenga el transporte exterior propio del túnel y una ruta de gestión fuera de banda separados del tráfico reenviado. Si la única forma de reparar la puerta de enlace es a través del túnel que está depurando, el laboratorio se convierte en un ejercicio de bloqueo. Una consola serie, un adaptador de gestión solo para el anfitrión o una instantánea de un estado bueno conocido son más baratos que recuperar a mano un enrutador roto.

Verifique el camino desde el invitado, no desde el anfitrión

Trabaje hacia fuera. Confirme que el cliente alcanza la dirección WAN de la puerta de enlace, luego el servidor a través de la puerta de enlace, luego que una conexión al puerto VPN sale y vuelve. Una captura en ambas interfaces de la puerta de enlace muestra si la respuesta llega y se descarta en el camino de vuelta, algo que una captura solo en el cliente no puede distinguir:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Luego demuestre la salida. Pregunte desde el invitado a un servicio de reflexión de direcciones qué origen ve y compárelo con la dirección de salida de la puerta de enlace; si la respuesta coincide con la dirección del anfitrión, existe un camino alrededor del túnel. Compruebe qué resolutor usa realmente el invitado, y compruebe IPv6 por separado, porque un segmento donde IPv6 está activado mientras el túnel solo lleva IPv4 filtra por diseño y no por accidente.

Por último, rómpalo a propósito. Detenga el túnel, o bloquee su puerto exterior, y abra una conexión nueva desde el invitado. Debe fallar, y el motivo debe ser uno que pueda nombrar: ninguna ruta, una regla de rechazo o un resolutor muerto. Reinicie el túnel y confirme que el invitado se recupera sin reconstruir la red. Si una VPN de malla como Hamachi o ZeroTier comparte el laboratorio, recuerde que un adaptador puente sigue el nombre del adaptador, no la malla, así que el puente debe reorientarse después de que el cliente instale su propio adaptador virtual.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Compartir el túnel de un invitado con el anfitrión refleja el problema. Apuntar la ruta predeterminada del anfitrión al invitado funciona, y también un proxy dentro del invitado; el NAT a través del anfitrión no lleva el túnel del invitado para el tráfico que el anfitrión originó. Guarde los nombres de los segmentos y las reglas del cortafuegos en un solo lugar, tome una instantánea del estado que funciona y anote la dirección de origen que observó el servidor. El siguiente cambio de perfil costará entonces una ejecución de script en lugar de un laboratorio reconstruido.