Acotar una puerta de enlace OpenVPN a una sola LAN con reglas de UFW

Decida el permiso antes de abrir un archivo de cortafuegos: los clientes autenticados pueden abrir conexiones hacia una subred concreta, y la puerta de enlace debe rechazar cualquier otra ruta de tránsito incluso cuando un cliente instale rutas adicionales. Esa frase es el diseño, y cada regla de abajo existe para hacerla cumplir. Algo más amplio, como todo el espacio de direcciones privadas, la salida a internet por el túnel o el tráfico entre pares, es un diseño distinto que necesita su propia decisión. Las reglas también son deliberadamente aburridas, porque un cortafuegos ingenioso es uno que nadie podrá auditar después.

Escriba primero la topología y el permiso

El ejemplo usa un servidor Community OpenVPN con un dispositivo TUN en espacio de usuario llamado tun0, un grupo de clientes 10.77.0.0/24, y una subred conectada 192.168.60.0/24 en lan0. El reenvío IPv4 ya funciona y la LAN ya tiene una ruta de vuelta al grupo, así que nada aquí depende de la traducción entre ambos.

UFW es el dueño del cortafuegos en este host, y ni un conjunto de reglas de contenedor ni una tabla nftables separada pueden instalar una ruta de aceptación anterior. Un atajo de descarga de flujo que se salte el filtro haría decorativas las cadenas de guardia, así que confirme que ninguna está activa. Deje el reenvío client-to-client propio de OpenVPN desactivado, porque el tráfico entre pares que nunca cruza el filtro del sistema operativo no se puede acotar con él. El escucha externo y las reglas de administración se quedan como están, ya que este cambio gobierna el tráfico descifrado del túnel en lugar de reemplazar el cortafuegos.

Coloque los guardias antes de las aceptaciones tempranas de UFW

Un permiso de ruta seguido de una denegación no basta para un límite estricto. Las reglas before de serie aceptan el tráfico establecido y algunos ICMP antes de que se consulte cualquier regla de usuario, así que un flujo permitido la semana pasada puede quedar fuera de la nueva restricción de destino solo porque aún tiene estado. Haga copia de seguridad de los archivos de UFW y mantenga abierta una consola fuera de banda antes de editar.

En la sección *filter del archivo /etc/ufw/before.rules, declare dos cadenas junto a las declaraciones existentes y antes de cualquier línea de regla.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Justo después de las declaraciones, y antes de los permisos de entrada y de reenvío, salte a ellas y defina qué admiten.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Conserve el resto de la sección y su línea COMMIT. Pegar una segunda tabla de filtro o borrar reglas no relacionadas es como un cambio de cortafuegos se convierte en una caída, y el archivo está a un reinicio de ser la única copia que importa.

Lea qué admite y rechaza cada guardia

La primera cadena continúa el procesamiento solo cuando el origen está en el grupo, el destino es la única subred, la interfaz de salida es la LAN y el paquete viaja en la dirección original de su flujo. Todo lo demás que llega del túnel se descarta, incluido un origen fuera del grupo y cualquier destino más allá de la subred permitida.

Un paquete entre pares entra y sale por tun0, así que falla la prueba de interfaz de la LAN antes incluso de llegar a la comprobación de destino. Las conexiones nuevas desde la LAN hacia los clientes también fallan la prueba de dirección de respuesta, lo que cierra por defecto la ruta de llamada inversa.

El objetivo RETURN mantiene en juego la política normal de UFW. Estas cadenas filtran, y el permiso de ruta que añada después sigue decidiendo si un paquete superviviente se acepta. Esa separación es la que le permite cambiar la subred permitida en un solo lugar más adelante. Si los guardias aceptaran los paquetes directamente, cada regla futura tendría que añadirse dos veces.

Autorice la subred y cierre las puertas laterales

Previsualice primero el permiso de ruta y luego quite la bandera de vista previa para aplicarlo: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Después revise el orden de las reglas de usuario, porque una denegación anterior sigue ganando a una autorización posterior. Un permiso para toda la subred también es la forma equivocada cuando solo debe ser accesible el puerto HTTPS de un host.

Fíjese en qué hace el descarte de entrada: los clientes del túnel no pueden alcanzar ningún servicio en la propia puerta de enlace, incluido un escucha DNS ligado a su dirección de LAN. Alojar DNS allí exige una excepción deliberada antes del descarte y un contrato de permiso revisado. Si UFW gestiona IPv6, añada descartes equivalentes para tun0 en before6.rules también, porque una lista de destinos IPv4 no dice nada sobre los paquetes IPv6.

Verifique la política cargada, no la vista previa

Previsualice la recarga, aplíquela en una ventana de mantenimiento y lea el conjunto de reglas vivo.

sudo ufw --dry-run reload
sudo ufw show raw

Confirme que los guardias del túnel aparecen antes de los permisos por defecto de estado e ICMP. El ufw status simple no muestra las reglas before editadas a mano, y por eso los operadores concluyen que falta una regla cuando en realidad está cargada. Lea el listado en bruto de arriba abajo en lugar de buscar un fragmento. Si los guardias aparecen después de un permiso de estado, el límite no hace lo que sugiere el archivo.

Luego pruebe el comportamiento, no el texto. Abra una conexión nueva a un host permitido y observe la respuesta, dirija una petición inofensiva a un destino fuera de la subred y confirme que muere, pruebe una conexión entre pares, pruebe un servicio local a la puerta de enlace y pruebe una conexión no solicitada de la LAN hacia un cliente. Incluya un flujo fuera de alcance que existiera antes del cambio, y borre solo ese flujo en lugar de vaciar toda la tabla de seguimiento de la máquina.

Anote los límites junto a las reglas: esto acota el tránsito y nada más. No impide que un cliente use su propia conexión a internet, no impide que un host permitido de la LAN retransmita tráfico hacia fuera, y no sustituye la autenticación dentro de los servicios permitidos.