Cómo solucionar problemas de FirewallD en linux

 Le pedimos  a Gemini, la inteligenia artificial de Google que nos explique cómo solucionar problemas de FirewallD en linux

Explicanos detalladamente cómo solucionar problemas de FirewallD en linux

Solucionar problemas de FirewallD en Linux requiere entender su sistema basado en Zonas y cómo interactúa con systemd. Los fallos más comunes se deben a la asignación incorrecta de una interfaz a una Zona, reglas temporales no aplicadas permanentemente o conflictos de servicios.

Aquí te explicamos detalladamente cómo diagnosticar y solucionar los problemas más frecuentes de FirewallD. 🛠️

1. Diagnóstico Inicial: Estado y Zonas Activas

Antes de modificar reglas, confirma que el servicio se esté ejecutando y que tus interfaces estén en las Zonas correctas.

Verificar el Estado del Servicio: Asegúrate de que FirewallD esté activo y funcionando.

Bash

sudo systemctl status firewalld

Si está inactive (dead): Inícialo y habilítalo para el arranque.

Bash

sudo systemctl start firewalld

sudo systemctl enable firewalld

Si está active (running): Procede al siguiente paso.

Verificar Zonas y Interfaces Activas: Confirma qué interfaz de red (ej., eth0, enp0s3) está asignada a qué Zona.

Bash

sudo firewall-cmd --get-active-zones

Problema: Si tu interfaz está en la zona drop (la más restrictiva) o public (si estás en una red interna confiable), es posible que el tráfico local esté bloqueado.

Solución: Mueve la interfaz a una Zona más adecuada (ej., home o internal).

Bash

# Mover eth0 a la zona 'home' de forma permanente

sudo firewall-cmd --zone=home --change-interface=eth0 --permanent

sudo firewall-cmd --reload

2. Problemas de Bloqueo de Conexiones (El Firewall es Demasiado Restrictivo)

Si un servicio no es accesible desde afuera o desde adentro, la regla del firewall suele ser la causa.

A. El Servicio Entrante Está Bloqueado

Diagnóstico: Intentas conectarte a un puerto (ej., 80 para web) y la conexión falla.

Causa: La regla allow no se ha añadido, o no se aplicó de forma permanente.

Solución:

Verificar Reglas por Zona: Lista todas las reglas para la Zona que estás usando (ej., public).

Bash

sudo firewall-cmd --list-all --zone=public

Comprobar la Persistencia: Si ves que el servicio o puerto que abriste no está listado en la sección services o ports, es probable que no hayas usado la bandera --permanent.

Añadir/Reaplicar la Regla (Permanente): Vuelve a añadir el servicio o puerto, asegurándote de usar la bandera --permanent y recargando el firewall.

Bash

# Ejemplo: Abrir puerto TCP 8080 permanentemente

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent

# Aplicar el cambio

sudo firewall-cmd --reload

B. El Tráfico de Salida Está Bloqueado

Diagnóstico: El servidor no puede iniciar conexiones hacia Internet (ej., fallan las actualizaciones dnf o apt).

Causa: La política predeterminada de la Zona es demasiado estricta o hay una regla de rechazo explícita.

Solución:

Revisa la Zona: Si estás en la zona drop o block, por defecto se bloquea el tráfico saliente.

Mueve a public: La zona public permite el tráfico de salida por defecto (ACCEPT en la cadena OUTPUT). Mueve la interfaz a una zona menos restrictiva (ver Paso 1.B).

3. Uso de Logs (Registro) para el Diagnóstico Avanzado

Si no sabes qué regla está causando el bloqueo, el registro de FirewallD te lo dirá.

Habilitar el Registro de Paquetes Rechazados: Puedes añadir una regla a la Zona para registrar el tráfico que está siendo rechazado.

Bash

# Añade una regla para registrar paquetes rechazados a la zona 'public'

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule protocol value="all" LOG prefix="FIREWALL-REJECT: " level="info" limit value="1/m"'

sudo firewall-cmd --reload

Monitorear los Logs: Una vez habilitado el registro, monitorea el archivo de logs de tu sistema (generalmente journalctl en la mayoría de las distribuciones modernas).

Bash

# Monitorear logs en tiempo real y filtrar por el prefijo

sudo journalctl -f | grep FIREWALL-REJECT

Cuando intentes realizar la conexión fallida, verás una línea con la IP de origen, el puerto y el protocolo. Esta información te indica exactamente qué regla de ALLOW necesitas crear.

4. Soluciones Avanzadas y Reseteo

A. Fallos en el Servicio después de un Reinicio

Diagnóstico: El servicio arranca, pero no carga las reglas.

Causa: Archivos de configuración XML corruptos en el directorio /etc/firewalld/.

Solución:

Verificar Sintaxis: Revisa si los archivos XML que has modificado tienen errores.

Revertir a la Configuración de Fábrica: Si la configuración está corrupta, puedes eliminar el directorio /etc/firewalld/ y reinstalar el paquete para restaurar los valores predeterminados.

Bash

sudo rm -rf /etc/firewalld/

sudo dnf reinstall firewalld # O apt install --reinstall firewalld

sudo systemctl start firewalld

B. Conflicto con Otros Servicios de Firewall

Diagnóstico: Las reglas que configuras no tienen ningún efecto, o ves errores de iptables.

Causa: UFW o las reglas de iptables se están ejecutando simultáneamente y están interfiriendo con FirewallD.

Solución: Asegúrate de que solo FirewallD esté activo y en control de netfilter.

Bash

sudo systemctl stop ufw

sudo systemctl disable ufw

# Limpiar reglas persistentes de iptables si existen

sudo iptables -F

Con estos pasos, podrás diagnosticar con precisión si FirewallD es la causa de tus problemas y aplicar las correcciones permanentes usando el sistema de Zonas y reglas dinámicas.