Zona VPN de OpenWrt, reenvío y enmascaramiento: ¿cuál necesita?

Tres cambios se mezclan cada vez que una VPN se encuentra con OpenWrt: abrir un puerto, permitir el reenvío y activar el enmascaramiento. Responden a preguntas distintas, y normalmente solo uno de ellos es el requisito real. Leer cada control según el papel del tráfico que gobierna convierte una suposición en una decisión, y además dice qué síntoma esperar cuando el cambio es incorrecto. Empiece por nombrar el papel que falló, no la casilla que recuerda.

Nombre el papel del tráfico antes de tocar un control

La entrada de zona decide qué puede llegar al propio router. La salida de zona cubre el tráfico que origina el router, el reenvío de zona es el valor predeterminado para el tráfico que atraviesa una zona, y el enmascaramiento decide si la dirección de origen se reescribe a la salida. Son cuatro preguntas distintas, y una política de zona las responde todas a la vez con el mismo valor, por eso un cambio en toda la zona es un instrumento tosco. Una regla con nombre puede responder a una de ellas sin tocar las demás.

El mapa útil es por papel del tráfico, porque eso es lo que puede observar cuando algo falla. Cada papel de abajo tiene un control que lo decide y un síntoma que apunta a él:

Un servicio a la escucha en el router necesita una sola regla de entrada estrecha

Un servidor OpenVPN en el router recibe tráfico dirigido al router, así que su conexión exterior depende de la política de entrada de la zona que lo transporta. Permita el transporte y el puerto configurados y deje todo lo demás de esa zona en rechazo. Una sola regla de puerto es un cambio mucho menor que una aceptación en toda la zona, y es la que todavía podrá explicar dentro de un año.

Dos cosas hacen que esa regla sea segura de mantener: nombra el puerto que el servicio usa de verdad y está junto a la definición de la zona para que la siguiente persona vea por qué existe. Las líneas de abajo son la forma, con el puerto en lugar de lo que esté configurado en el servidor. Cambie ese puerto en ambos sitios cuando el servicio se mueva, porque una regla que se queda en el antiguo es invisible hasta una auditoría.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valide antes de recargar, porque un error de sintaxis en un archivo de cortafuegos puede dejar el router sin un conjunto de reglas funcional. En una versión que usa fw4 la comprobación es un comando aparte, y falla ruidosamente en lugar de aceptar en silencio un bloque roto. Recargue solo después de que la comprobación pase y guarde el archivo anterior donde pueda devolverlo.

fw4 check
service firewall reload

La petición de un cliente cruza el reenvío, no la entrada

Después de la autenticación, la petición de un cliente de túnel a un servicio de la LAN produce un flujo reenviado, así que el control que la decide es la relación de reenvío entre la zona del túnel y la zona LAN. Asigne la interfaz del túnel a la zona prevista y luego declare la dirección, las fuentes y el servicio. La asignación de zona es lo que da sentido a la regla de reenvío, y ambas solo se entienden leídas juntas. Una relación de reenvío que nombra la zona del túnel como origen y la zona LAN como destino se lee como una decisión deliberada, mientras que dos aceptaciones en toda la zona se leen como un accidente.

Llegar al propio router sigue usando la ruta de entrada, por eso un ping a la puerta de enlace no dice nada sobre el recurso compartido que hay detrás. Esos dos fallos viven en bloques distintos y se corrigen con ediciones distintas. Escriba ambas rutas por separado antes de cambiar cualquiera de ellas.

El enmascaramiento es una decisión de encaminamiento, no un permiso

El enmascaramiento reescribe la dirección de origen del tráfico de salida seleccionado. Puede rescatar un diseño de salida en el que el lado remoto no tiene ruta de vuelta, y también oculta las direcciones de clientes individuales a cualquier servicio que registre o autorice por dirección. Desactivarlo es una elección de encaminamiento sobre la ruta de vuelta, no un interruptor de seguridad que cierra un agujero de entrada. Un túnel que funciona con la traducción activada y falla en el momento de desactivarla suele tener una ruta de vuelta que falta, no una regla de cortafuegos que falta.

La alternativa enrutada necesita una ruta de vuelta en el lado remoto en lugar de la traducción. Ninguna de las dos opciones proporciona el permiso del cortafuegos ni la cuenta de la aplicación, por eso desactivar el enmascaramiento casi nunca arregla un cliente de túnel que no puede llegar a nada. Trate también la política IPv4 y la IPv6 por separado, porque un solo ajuste de traducción no describe las dos familias.

Demuestre la decisión con una petición permitida y otra rechazada

Envíe una petición que debería permitirse y otra que debería rechazarse, y luego identifique el control que tomó cada decisión. Una página que se carga por casualidad no es prueba; la prueba es la regla que coincidió, en la cadena donde coincidió. El rechazo importa tanto como el éxito, porque muestra que la política hace algo en lugar de que todo esté permitido.

Dos comandos le dan esa prueba en una versión actual. El contador de la regla correspondiente se mueve cuando la petición se acepta, y el registro muestra el descarte si ha activado el registro para la regla:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Conserve una ruta de administración que todavía pueda usar antes de cambiar cualquier política de cortafuegos, y siga el proceso de validación y reversión del propietario de la configuración. Un cambio que le deja fuera del router no es un resultado de prueba, es un segundo incidente. Anote la zona y el papel del tráfico junto a cada observación, para que el par de resultados explique la política en lugar de describir una carga de página afortunada.