Delimite la regla SNAT de OpenVPN antes de que rompa nginx

Dos fallos llegan siempre del mismo tipo de host. En el primero, los clientes se autentican y después no alcanzan nada más allá del túnel. En el segundo, la VPN sube y el propio sitio web del servidor deja de responder, que es el más alarmante porque parece daño colateral. En un VPS basado en contenedores ambos suelen remontarse a la misma lista corta de comprobaciones, y el orden importa: primero el dispositivo, segundo la traducción, tercero el alcance.

Confirme que el contenedor puede crear un dispositivo tun

Nada más importa si la interfaz del túnel no puede existir. Compruebe que /dev/net/tun está presente y que la creación de un dispositivo de prueba tiene éxito, porque muchos proveedores desactivan tun dentro de los contenedores por defecto. Ninguna cantidad de trabajo con firewall compensa un dispositivo que nunca se creó.

Si falta el dispositivo, solo el host o el proveedor pueden habilitarlo. A menudo un plan distinto es más barato que un hilo de soporte abierto que dura una semana. Confírmelo antes de leer una sola línea del registro de OpenVPN. De lo contrario pasará la velada ajustando reglas que nunca verán un paquete.

Decida qué hace MASQUERADE en esta interfaz

En una máquina virtual corriente la regla de salida habitual es POSTROUTING MASQUERADE de la interfaz principal. En un contenedor OpenVZ el dispositivo visible suele ser venet0, una interfaz virtual gestionada por el host y no una NIC enrutada, y MASQUERADE no siempre se comporta allí como suponen los tutoriales.

La forma viable es una traducción explícita a la dirección que los clientes ya alcanzan, con el reenvío permitido en ambos sentidos. Sustituir el pool de la configuración del servidor importa tanto como sustituir la dirección. Lea cada línea antes de pegarla.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sin las reglas de reenvío la traducción sigue ocurriendo y el kernel sigue negándose a reenviar. Esa combinación produce el estado confuso en el que los contadores de la regla NAT suben mientras el cliente no recibe nada. Las dos líneas FORWARD también deben ir antes de cualquier regla drop amplia en la misma cadena. El orden es parte de la configuración, no un detalle de implementación.

Delimite la regla a un pool y una interfaz

El segundo síntoma tiene otra causa: una regla POSTROUTING sin restricción de origen ni de salida. Tal regla reescribe cada paquete que sale del host.

Los servicios que dependen del origen original se comportan mal. Un servidor web detrás de un proxy local puede dejar de responder, y reiniciarlo no cambia nada porque la regla sigue en el camino. El tráfico que el host envía a su propia dirección pública también se ve afectado, por eso el fallo puede parecer un problema de DNS o de certificado en lugar de uno de firewall. La regla casi con seguridad se añadió para arreglar el primer síntoma.

La solución es estrechar la coincidencia al pool del túnel y a la interfaz de salida, y luego añadir una regla por pool en lugar de ampliar una sola regla para cubrir varias.

Haga persistentes las reglas y averigüe quién más es su dueño

Las reglas añadidas a mano desaparecen al reiniciar, así que guárdelas con iptables-save o adminístrelas mediante netfilter-persistent donde esté instalado. Confirme que la restauración se ejecuta antes de que arranque OpenVPN. Después reinicie una vez a propósito en lugar de descubrir el hueco durante un incidente.

En un host de contenedores, confirme también que el archivo de persistencia vive en almacenamiento de contenedor escribible y que el proveedor no sustituye el filtrado al arrancar. Algunas plataformas gestionan la política fuera del contenedor, donde las reglas locales o se ignoran o chocan con las del propio host.

Verifique con contadores y un flujo capturado

Desde un cliente conectado, compruebe la dirección pública que informa un servicio externo. Si coincide con la dirección del servidor, la traducción funciona; si no, el paquete sale por otro camino o no sale en absoluto. Después pruebe tanto un servicio alojado en el servidor como uno en la internet pública, porque toman caminos distintos por el mismo conjunto de reglas.

En el servidor, lea los contadores de paquetes de las reglas NAT y FORWARD con iptables -t nat -L -v -n y observe un flujo en una captura. Si la dirección del cliente aparece en la captura y no sigue ninguna respuesta, el hueco está en el camino de vuelta o en el filtrado del proveedor, no en el perfil del cliente. Compare el origen capturado con la dirección a la que traduce la regla, porque una discrepancia significa que otra regla coincidió primero. Un solo flujo observado resuelve más que una página de lectura de configuración.

Mantenga el pool, la dirección traducida y el nombre de la interfaz juntos en el registro de cambios. Una regla correcta para un pool traduce mal la siguiente.