iptables: deje que los clientes VPN lleguen a un solo equipo y a nada más

Dos tickets de soporte que parecen no tener relación resultan compartir una causa. En el primero, un administrador quiere que el servidor acepte conexiones solo del túnel; en el segundo, los usuarios de VPN deberían llegar a un único equipo interno y a nada más. Ambas políticas pertenecen a FORWARD, y ambas suelen intentarse en INPUT. El resultado parece un cortafuegos y se comporta como un marcador de posición.

Qué cadena responde a su pregunta

Los paquetes que un cliente VPN envía a un equipo de la LAN, o más allá hacia internet, los reenvía el núcleo y se evalúan en FORWARD. INPUT y OUTPUT solo ven el tráfico que termina en el servidor o que se origina en él. Por eso, un rechazo para todo lo que no llega por tun0 protege a los propios oyentes del servidor y además terminará su sesión SSH salvo que primero se admitan los flujos establecidos. No cambia nada sobre adónde pueden ir los clientes.

Primero ponga nombre a la pregunta: quién puede llegar al servidor o adónde pueden ir los clientes. La mayoría de las redes necesita ambas respuestas, en cadenas distintas.

Primero el estado, luego el permiso y luego la negativa

Una lista de permitidos solo funciona si el permiso concreto queda por encima de la negativa general y si el tráfico de vuelta se admite por encima de ambos. Inserte las reglas en posiciones explícitas y luego vuelque la cadena con iptables -S FORWARD para que el orden sea visible y no supuesto.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dos detalles deciden si esto sobrevive al contacto con tráfico real. Sin la regla de estado, las respuestas a las conexiones que acaba de permitir se evalúan ellas mismas contra la negativa y se descartan. Una regla LOG sin límite puede agotar una partición pequeña la primera vez que un escaneo la alcanza, así que añada -m limit --limit 10/min antes de seguir registrando. REJECT devuelve un error de inmediato, lo que resulta más amable mientras ajusta la lista; DROP descarta en silencio, así que cada error se presenta como un tiempo de espera agotado. Elija uno a propósito y escriba la elección en el registro de cambios.

El reenvío y el NAT ya deben funcionar

El filtrado no puede demostrar que exista un camino. Confirme primero que el núcleo reenvía siquiera, y haga ese ajuste persistente en lugar de un comando puntual en la shell. El filtro es la última capa, no la primera.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Dónde va el enmascaramiento depende de por dónde salen los clientes. Si salen hacia una red remota a través del túnel, la regla NAT va en esa interfaz y no en la interfaz WAN. Luego mire los contadores: si el contador de POSTROUTING nunca se mueve mientras el número de admisiones en FORWARD sube, el camino de vuelta está roto y el filtro está bien. Esa lectura ahorra una tarde reescribiendo reglas que nunca fueron el problema.

El bloque de correo pertenece una cadena más allá

Bloquear el puerto 25 en INPUT solo detiene el correo dirigido al servidor VPN. Un cliente comprometido que envía correo por el túnel se reenvía, así que el bloque debe estar en FORWARD junto a 465 y 587. Si una aplicación retransmite correo de forma legítima, ponga su destino y su puerto por encima de esa regla.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Deje correr el contador de rechazos una semana antes de apretar cualquier otra cosa. El número que deja de subir es el flujo legítimo que acaba de romper.

Vuelva a leerlo y luego demuéstrelo desde un cliente

Lea el conjunto de reglas tal como lo informa el núcleo, no como lo escribió su script. Empiece con iptables -S FORWARD, luego la tabla NAT con iptables -t nat -L POSTROUTING -n -v, luego la entrada de conntrack del flujo que está probando. Mantenga un comando de reversión o un vaciado programado mientras dure el trabajo. Cada invocación necesita -w, o dos administradores chocarán en el bloqueo de xtables. Nada de eso es opcional durante una ventana de cambios.

Termine probando desde un cliente dentro del grupo y desde uno fuera de él. Una regla que solo funciona desde la máquina donde la escribió no es una política.