OpenVPN de túnel completo: añada una salida a internet en el lado del servidor

Un cliente se autentica, recibe una dirección del grupo y llega a los servicios del host VPN, pero todo destino público termina en tiempo de espera. Así se ve un túnel sin salida, y así sigue hasta que se cumplen cuatro cosas distintas. El cliente debe aceptar una ruta predeterminada, el servidor debe reenviar, el cortafuegos debe permitir el tránsito y las respuestas necesitan un camino de vuelta al grupo. Los cuatro fallos comparten un solo síntoma, así que cambie un elemento por intento y anote el resultado.

Empuje la ruta predeterminada y confirme qué instaló el cliente

La línea del lado del servidor es corta, y solo afecta a los clientes que aceptan opciones empujadas. La forma def1 instala dos rutas medio predeterminadas en lugar de borrar la predeterminada existente, lo que mantiene viva la conexión actual y a la vez captura todos los destinos.

push "redirect-gateway def1"

Tras reconectar, lea la tabla de rutas del cliente en lugar de confiar en el perfil. En Linux las dos entradas /1 aparecen junto a la ruta predeterminada original, y Windows muestra el mismo par como 0.0.0.0/1 y 128.0.0.0/1. Un cliente que ignora las opciones empujadas, o uno configurado para rechazarlas, conserva su ruta predeterminada antigua y nunca envía tráfico de internet al túnel. Resuelva esa cuestión antes de cambiar nada en el servidor, porque ninguna regla del lado del servidor puede compensarlo.

El reenvío es un ajuste del servidor, no del VPN

Lea el indicador de reenvío antes de tocar el enrutamiento. Un cero ahí significa que el núcleo recibe el paquete del cliente y se niega a pasarlo, lo que parece exactamente un bloqueo del cortafuegos desde el extremo remoto. Fije el valor a través del directorio de configuración del sistema para que sobreviva a un reinicio.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

A continuación, confirme que el propio host tiene una ruta funcional hacia la salida a internet. Una petición desde el shell del servidor demuestra que la ruta ascendente es utilizable y no dice absolutamente nada sobre reenviar el paquete de un cliente, así que trátelas como dos pruebas separadas. Si el servidor no puede alcanzar el destino, ninguna cantidad de configuración de reenvío ayudará.

Permita el tránsito que pretende, y nada más

Los paquetes reenviados cruzan la ruta forward; el tráfico dirigido al propio host VPN cruza input. Son decisiones distintas, y abrir la ruta input no permite el tránsito por la máquina. Confundirlas es la razón más común de que un cortafuegos parezca permitirlo todo mientras los clientes siguen agotando el tiempo.

Una política mínima acepta conexiones nuevas del grupo hacia la interfaz de salida y acepta las respuestas que pertenecen a flujos establecidos. Póngala en el propietario de conjunto de reglas que use su distribución, en lugar de añadir una regla duplicada en cada arranque; las reglas duplicadas se acumulan y los contadores dejan de significar nada.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Cambiar cada cadena a aceptar hace que la prueba pase y elimina la razón de existir del cortafuegos. Mantenga el alcance en el grupo y la interfaz de salida, y deje en paz el reenvío no relacionado.

Dé a las respuestas un lugar al que ir

Las direcciones del grupo son privadas, así que un servidor público no puede entregarles una respuesta directamente. O el host VPN traduce la dirección de origen a la salida, o un dispositivo aguas arriba mantiene una ruta de vuelta al grupo.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Añada exactamente una capa de traducción. Un segundo NAT más arriba oculta el primero y hace que ambos registros sean casi inútiles cuando algo se rompe después. Si un router aguas arriba ya encamina el grupo de vuelta, añadir traducción en el host es redundante, y el camino de vuelta depende entonces de la configuración de ese router y no de la suya.

Las instancias en la nube añaden una puerta más, porque algunas plataformas descartan paquetes cuya dirección de origen no es la de la instancia salvo que se relaje esa comprobación. Ese ajuste está fuera del invitado y es fácil de olvidar cuando una máquina de prueba local funciona.

Demuéstrelo desde el cliente, no desde el shell del servidor

Empiece con una petición IPv4 numérica, luego una consulta de nombre, luego la aplicación. Un ping demuestra el reenvío y la traducción;no demuestra nada sobre la resolución, porque las opciones de DNS solo surten efecto cuando la integración del cliente las instala.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Anote los cambios y el paso de deshacer sobre la marcha, para que la política de salida pueda revertirse en una sola acción cuando una prueba falle. Esta receta cubre solo IPv4; haga inventario de IPv6 por separado antes de afirmar que el despliegue transporta todo el tráfico.