Host iptables solo con VPN: nombre el dispositivo tun, no tun+

Escribir -o tun+ parece una instrucción precisa y en realidad es un comodín que abarca todos los túneles que tiene el núcleo. Un segundo cliente VPN, un puente de contenedores o una interfaz que dejó una sesión caída los satisfacen todos, y el host entonces permite tráfico que la política pretendía impedir. El procedimiento de abajo fija un nombre de dispositivo, ordena las excepciones para que el túnel pueda formarse de verdad y le deja una vía de vuelta si las reglas salen mal. Cada paso es lo bastante corto para deshacerlo por separado.

Paso 1: anote las reglas que tiene ahora

Antes de cambiar una política predeterminada, guarde el estado actual para que la reversión sea un comando y no un recuerdo. iptables-save > /root/iptables.pre escribe cada tabla en un archivo que puede restaurar, y un segundo terminal con una sesión root abierta no es paranoia cuando la política que va a establecer corta la conexión que la transporta. Si trabaja en remoto, programe también un flush como interruptor de hombre muerto.

Después liste las interfaces, porque un nombre que supuso es un nombre que debería haber leído: ip -br link muestra lo que existe ahora mismo, y el túnel no aparecerá hasta que esté levantado. Apunte los nombres de los dispositivos a medida que los lee.

Paso 2: dé al túnel su propio nombre

OpenVPN acepta dev tun_work en la configuración del cliente, y entonces Linux crea una interfaz exactamente con ese nombre en lugar de asignar tun0. El nombre se mantiene estable entre reconexiones mientras nada más lo reclame, y eso es lo que hace significativa una regla que nombra el dispositivo.

Donde el nombre no se puede controlar, haga coincidir la dirección del túnel o una marca de paquete. Ambas funcionan, ambas son más difíciles de leer y ambas fallan más en silencio cuando el túnel cambia la numeración. En cualquier caso, haga coincidir una sola cosa y sea explícito sobre cuál.

Paso 3: escriba la política con la excepción del endpoint primero

Un host solo con VPN es un host de denegación predeterminada con una lista corta de excepciones, y la excepción que más importa es la que permite que el túnel exista. Constrúyala en este orden, con la regla del endpoint antes de la regla del dispositivo del túnel, para que el handshake tenga adónde ir:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

La dirección y el puerto literales del endpoint son de su proveedor, no de esta página. Si el endpoint es un nombre de host, resuélvalo una vez y fije el resultado, porque una regla no puede consultar un nombre y una respuesta que rota romperá la política en silencio tras el siguiente cambio de DNS. Compruebe también el puerto, porque los proveedores que le pasan a TCP 443 necesitarán si no una regla que nadie escribió. Un túnel que solo funciona con un protocolo suele ser esta omisión y no un fallo del cortafuegos.

En un router la misma forma va a la cadena FORWARD para los clientes que hay detrás, y el tráfico propio del router necesita sus propias reglas. Un conjunto de reglas que solo cubre paquetes reenviados deja SSH y DNS por el camino antiguo, y así es como un router se vuelve inalcanzable en el momento en que el túnel sube.

Paso 4: compruebe el orden, no solo la presencia

Las reglas se evalúan en secuencia, así que un ACCEPT que llega antes simplemente oculta el REJECT que añadió después. La coincidencia established y related es la que deja volver las respuestas a sus propias peticiones salientes sin abrir un camino de entrada general, y colocarla después de la aceptación del túnel significa que un túnel caído todavía deja pasar tráfico de vuelta por su propia interfaz.

Mantenga el número de reglas lo bastante pequeño para leerlo en una pantalla. Un conjunto de reglas que no puede auditar es uno que parcheará añadiendo excepciones arriba, y así es como las políticas de denegación predeterminada adquieren poco a poco un borde de permiso predeterminado. Cuente los ACCEPT antes y después del cambio.

Paso 5: haga que sobreviva al arranque y a la familia de direcciones

Las reglas introducidas a mano desaparecen al reiniciar, así que cárguelas desde el servicio de cortafuegos de la distribución o desde una unidad que se ejecuta después de que exista la interfaz del túnel. Referenciar tun_work en un script que se ejecuta antes de que arranque OpenVPN es una forma habitual de producir un bucle de arranque de tráfico descartado.

Después compruebe IPv6 por separado, porque una buena política de denegación predeterminada para IPv4 no dice nada sobre la otra familia. ip -6 route le dirá si el host tiene una ruta que pudiera llevar tráfico alrededor de un túnel que solo maneja IPv4, y ip6tables o nftables necesita sus propias reglas equivalentes. Pruebe con un destino IPv6-only en lugar de confiar en la simetría del conjunto de reglas.

Paso 6: verifique y esté listo para restaurar

Levante el túnel, confirme que el servicio previsto funciona y luego pruebe algo que la política debería rechazar. Restaure con iptables-restore < /root/iptables.pre si la respuesta le sorprende, y solo entonces empiece a editar reglas. La persistencia más una ruta de restauración probada es lo que hace de esto un cambio que puede hacer dos veces.