Un cortafuegos de la distribución Linux puede bloquear el tráfico de tu VPN

El túnel se levanta, el registro dice conectado y una aplicación sigue sin alcanzar nada. En un cliente Linux eso suele significar que el cortafuegos de la distribución filtra una ruta que el cliente VPN nunca gestionó. Dos gestores pueden estar activos a la vez, cada uno con sus propias ideas sobre la interfaz, la zona y la dirección del tráfico. Identificar al propietario antes de tocar nada es más rápido que probar reglas hasta que algo funcione.

Encuentra el gestor y el backend

Empieza por lo que está realmente cargado, no por lo que está instalado. Una distribución puede incluir firewalld, ufw y un servicio nftables sencillo, y solo uno de ellos posee el conjunto de reglas en ejecución. Los paquetes conviven sin problemas, y una regla introducida por el frontend equivocado nunca llega al núcleo. Lee el servicio activo y luego lee el conjunto de reglas que produjo.

El backend importa tanto como el frontend. Una instalación de firewalld puede impulsar nftables o el backend iptables antiguo según la versión y la configuración, y ambos producen una salida de inspección distinta. Anota la distribución, la versión y el backend en el ticket antes de comparar tu sistema con cualquier guía.

Ajusta la dirección y la interfaz

Una solicitud saliente del cliente, un receptor entrante y un paquete reenviado atraviesan ganchos diferentes, y una regla para uno no cubre los demás. Una zona que permite la LAN local a menudo no incluye la interfaz del túnel ni el conjunto de direcciones de la VPN. La interfaz del túnel suele aterrizar en la zona predeterminada, que con frecuencia es más estricta que la zona del adaptador físico. Esa discrepancia explica por qué la navegación funciona en la LAN y se detiene en el momento en que sube el túnel.

Pregunta qué dirección falló antes de elegir una regla. Una aplicación que no puede conectar hacia fuera necesita la ruta de salida, mientras que un servicio entrante necesita la ruta de entrada en la interfaz del túnel. Añadir una regla a la cadena equivocada produce un cambio que parece aplicado y no hace absolutamente nada.

Mantén de acuerdo a los propietarios de las reglas

El gancho de un cliente VPN, un entorno de ejecución de contenedores y el servicio de la distribución pueden modificar la red, y no se coordinan entre sí. Las reglas introducidas a mano desaparecen en la siguiente recarga, y las reglas insertadas en la cadena de un gestor pueden evaluarse en un orden que no pretendías. Usa la configuración persistente del gestor e inspecciona el conjunto de reglas resultante en lugar del archivo que escribiste. Desactivar todo el cortafuegos porque un servicio no es accesible cambia un problema pequeño por uno grande.

Los contadores estrechos son la forma barata de encontrar el flujo rechazado. Una regla de registro limitada a un destino y un puerto muestra si el descarte ocurre localmente sin capturar el tráfico de nadie más. Elimina la regla de registro cuando termine la investigación, porque es un diagnóstico y no una política, y la documentación de zonas de firewalld explica cómo se combinan interfaces y servicios.

Comprueba la corrección sin perder el bloqueo

Inspecciona el estado aplicado con el gestor que lo posee, usando comandos que coincidan con el backend que registraste. La lista siguiente supone que manda firewalld; sustituye por el equivalente de nftables o ufw en lugar de ejecutarlos todos. Mezclar herramientas en una sesión es como una máquina termina con dos conjuntos de reglas en conflicto.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

El primer comando nombra las zonas y las interfaces asignadas, lo que muestra dónde aterrizó realmente el túnel. El segundo imprime las reglas y servicios de una zona, así que puedes ver si la interfaz VPN está cubierta. La lista de nftables es la verdad fundamental del backend en uso, y una regla que solo existe en un archivo de configuración no aparece allí. Compara las tres salidas con la regla que añadiste, y la discrepancia suele nombrarse sola.

Después repite la solicitud original y el comportamiento de fallo que exiges. Un sitio que acaba de funcionar no basta si el mismo cambio eliminó el bloqueo del cliente, así que prueba también una ruta sin protección. Anota el gestor, el backend, la interfaz y el propósito de la regla, porque una actualización de paquete que reviva un segundo gestor reconstruirá todo el desastre.