Dónde va el NAT de VPN en before.rules de UFW y cómo probarlo

Una regla NAT que funciona al escribirla en un shell falla al pegarla en before.rules, porque ese archivo no es un script. Es un documento en formato de restauración con secciones de tabla, declaraciones de cadena y una marca COMMIT por cada tabla. Una línea en el lugar equivocado o aborta toda la restauración o descarta en silencio reglas que usted creía presentes. El procedimiento siguiente coloca el fragmento donde el marco lo espera y demuestra el resultado antes de la próxima recarga.

Un comando de shell no es un archivo de restauración

Una línea que empieza por iptables -t nat es una instrucción para el binario iptables, mientras que el archivo que lee UFW es la descripción de un conjunto de reglas completo. La diferencia no es cosmética: el formato de restauración debe saber en qué tabla está, qué cadenas existen y dónde termina la tabla. Un comando pegado en ese documento es o un error de sintaxis o, peor, una regla adosada a la tabla equivocada. El marco carga esos archivos mediante herramientas de restauración precisamente porque son declarativos y no secuenciales.

El documento también se carga como un todo, así que una sección mal formada puede impedir que se aplique el resto del archivo. Por eso un pequeño error en un fragmento NAT se lleva consigo las reglas de filtrado, y así es como un cambio de cortafuegos se convierte en una caída.

Ponga el fragmento dentro de la sección de tabla existente

Un fragmento NAT tiene una forma, y la forma importa más que el texto de la regla que contiene. La cabecera de tabla abre la sección, las declaraciones de cadena establecen los contadores, siguen las reglas y un COMMIT cierra la sección.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

El grupo y la interfaz de arriba son marcadores para los suyos; la estructura es la parte que merece copiarse. Si el archivo ya contiene una sección *nat, añada la regla dentro de esa sección en lugar de abrir una segunda, porque el formato espera un COMMIT por tabla y dos secciones para la misma tabla son una reparación esperando a ocurrir. Mantenga intactas las definiciones de cadena de la distribución, incluidas las que el proveedor añadió para su propia integración. El manual del marco UFW documenta los archivos before, user y after junto con el requisito de un COMMIT coincidente.

Si el archivo resulta estar vacío, no lo rellene con un tutorial. Confirme qué paquete lo posee y cuál es la política activa en realidad, porque un archivo persistente vacío no demuestra que el núcleo no tenga reglas, y un conjunto de reglas cargado no demuestra que la próxima recarga tenga un archivo completo que leer. Restaure primero la línea base admitida y después vuelva a aplicar los cambios del sitio encima.

Pruebe el candidato sin aplicarlo

La herramienta de restauración puede analizar y construir un conjunto de reglas sin aplicarlo, que es la prueba más barata disponible. Ejecútela contra una copia protegida en lugar del archivo activo, y lea el texto del error en vez de solo el estado de salida. Un fallo de análisis nombra una línea y normalmente una tabla, lo que es más de lo que le dirá una recarga fallida.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Pasar esa comprobación demuestra que el documento se analiza y nada más. No demuestra que el candidato siga conteniendo todas las cadenas de las que depende UFW, que solo permita las fuentes que pretendía o que la administración remota siga siendo accesible. Son revisiones separadas, y la última merece una segunda sesión abierta antes de empezar.

Elija la herramienta que corresponda al backend instalado y a la familia de direcciones. Un host que ejecuta el backend nft a través de la capa de compatibilidad necesita el comando correspondiente, y las reglas IPv6 viven en un archivo completamente distinto.

Mantenga separados el reenvío, el NAT y la política de acceso

La traducción de origen resuelve un problema de direccionamiento y no concede nada. El reenvío es un permiso aparte que controlan un sysctl y la tabla de filtrado, y es el que la gente olvida cuando un túnel enruta pero no pasa tráfico. La política de acceso es una tercera decisión sobre qué fuentes pueden llegar a qué servicios, y ninguna regla NAT la expresa. Mantener los tres separados es lo que hace que un fallo sea diagnosticable en lugar de un único síntoma vago.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Lea esas tres salidas juntas, no una a la vez. Una regla masquerade con el reenvío desactivado produce un cliente que se conecta y no llega a nada, lo que desde el lado del cliente parece exactamente un fallo de enrutamiento y envía a la gente al archivo equivocado. La tabla de filtrado es también donde se esconde un accept demasiado amplio, así que revise su política por defecto mientras está ahí.

Verifique una recarga, una denegación y una pérdida de VPN

Tres observaciones componen una prueba de aceptación completa: la recarga tiene éxito, una operación de cliente permitida funciona y una petición que debería rechazarse se rechaza de verdad. La tercera es la que se omite, y es la única evidencia de que la política hace algo.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Después pruebe el fallo para el que diseñó. Deje caer el túnel y observe qué hace el host, porque una política que solo funciona mientras la VPN está activa es una política con una dependencia no declarada. Recargue una vez más después para demostrar que es el archivo, y no un estado de ejecución residual, lo que produce el resultado funcional.

El NAT de IPv4 no dice nada sobre IPv6, así que indique la cobertura prevista para ambas familias en la misma nota que la regla. El objetivo es una política gestionada coherente, y un fragmento que resultó analizable no es prueba de ella.