firewalld acepta respuesta a la consulta de DNS de multidifusión desde el puerto efímero

Estoy intentando configurar Firewalld (Fedora 21) para que las respuestas lleguen a las consultas MDNS enviadas desde una aplicación cliente usando un puerto de origen UDP efímero a un objective de multidifusión. Las respuestas son unicast. La secuencia es así (como se capturó usando wireshark)

  1. UDP: dirección local: 45325 (efímero) -> 224.0.0.251:5353; la consulta
  2. UDP: algún sistema: 5353 -> dirección local: 45325; la respuesta
  3. ICMP: dirección local -> some-system: Tipo: 3 (Destino inalcanzable), Código: 10 (Host administrativamente prohibido)

El service firewalld mdns, que agrega el puerto 5353 UDP está habilitado, pero esto no ayuda con la respuesta.

Cualquier indicador sería apreciada.

    Felicidades, descubriste una limitación en el concepto de filtrado de packages. Seguimiento de protocolos de multidifusión: la respuesta no puede regresar desde la misma dirección, porque está absolutamente prohibido enviar desde una dirección de multidifusión. El firewall no puede coincidir con la respuesta a su request, por lo que la bloquea. Obviamente, el sistema MDN dameon, avahi, lo evita enviando desde el puerto fijo 5353, por lo que es donde también recibe respuestas. El puerto 5353 está permitido específicamente por una regla de firewall. Si puede conseguir que el software hable con avahi , esa es la solución que avahi recomendaría.

    Alternativamente, es posible confiar en la opción avahi pnetworkingeterminada disallow-other-stacks=no , y configurar la aplicación cliente para usar el puerto fijo 5353 . No está claro qué efecto tiene esto en la fiabilidad de Avahi. O simplemente podría deshabilitar Avahi si no lo necesita. Por supuesto, si la aplicación te permite elegir un puerto fuente fijo, puedes agregarlo al firewall y funcionará …

    … excepto cuando dice "aplicación de cliente", probablemente se refiera a una class de software que, en teoría, debería poder ejecutar varias instancias al mismo time. No ejecuta todas las requestes de networking a través de un solo daemon. Y apuesto a que la aplicación no utiliza el hack SO_REUSEPORT que avahi implementa para disallow-other-stacks=no , por lo que esto solo le permitirá ejecutar una instancia de la aplicación a la vez .

    Una gran cantidad de software de Linux para escritorios o pequeñas cajas de networking local probablemente no está diseñado para ejecutarse con un server de security. Fedora es la distribución principal que lo hace. Fedora Workstation cambió recientemente su zona pnetworkingeterminada de firewall a "FedoraWorkstation", que permite conexiones a cualquier puerto TCP o UDP por encima de 1024. La configuration de FedoraWorkstation, o ejecutarse sin un firewall, permitiría que su software funcione sin cambios.

    Es difícil express el punto de un firewall host como Firewalld. No tiene soporte para el routing entre zonas como Shorewall. Le permite elegir establecer la zona pnetworkingeterminada en algo más restrictivo, con configuraciones más permisivas para su networking inalámbrica doméstica, o una VPN. Tal vez si trabajas duro en NetworkManager puedes hacer que funcione también para una networking cableada doméstica. Pero eso es tan oscuro para algo que está habilitado por defecto.

    Es totalmente seguro ejecutar una installation pnetworkingeterminada de Fedora (o Ubuntu) sin un firewall. A lo que renuncia es a una política centralizada para la cual los puertos están abiertos, en caso de que luego configure algún software aleatorio y no se dé count de que quiere escuchar en un puerto.

    La gente intenta comparar los firewalls en Linux y Windows, pero Windows Firewall es claramente necesario y realmente posible de entender por los mortales, a diferencia de Firewalld . Windows tiene puertos abiertos por defecto, y depende de un server de security para protegerlos. Implementa zonas confiables / no confiables para networkinges cableadas. Las networkinges nuevas se configuran de manera pnetworkingeterminada como no confiables, y aparece para preguntar si desea cambiarlo. Las diferentes networkinges cableadas se identifican por la dirección MAC del server DHCP. Al less desde Window 8, la primera ejecución "express" también marca la networking actual como de confianza, lo que me resulta teóricamente molesto, pero en la práctica probablemente sea bastante útil.

    Técnicamente, también podría modificar el software para hablar con Firewalld sobre dbus y solicitar que el puerto efímero al que se ató esté abierto para recibir respuestas. De alguna manera, no creo que sea una sugerencia útil.

    Tuve el mismo problema con un par de dispositivos específicos que se conectaban a un server. No importa lo que intenté, el firewall seguía bloqueando las requestes.

    Redhat recomienda dos methods, según la base de conocimiento:

    Solución 1:

    Abra el puerto UDP en el que estará el tráfico entrante:

     firewall-cmd --permanent --zone=public --add-port=12345/udp firewall-cmd --reload 

    Esto probablemente no funcionará porque el service mdns abre UDP 5353 y usted ha mencionado que esto no ayuda.

    Solución 2:

    Crea un service:

     <?xml version="1.0" encoding="utf-8"?> <service> <short>My Multicast Listener</short> <description>A service which allows traffic to a fictitious multicast listener.</description> <port protocol="udp" port="12345"/> <destination ipv4="224.0.0.251"/> </service> 

    Sin embargo, este ejemplo parece ser más saliente que entrante. En su lugar, podría intentar cambiar <destination> por <source address="xx.xx.xx.xx"> y ver si eso ayuda.

    Solución 3:

    Personalmente, no pude llegar a trabajar. Terminé básicamente en una list blanca de la IP de origen a todos los puertos. Algo que no recomendaría, pero me cansé de pasar horas jugando con firewalld y porque los clientes en cuestión son dispositivos Raspberry Pi en una LAN privada, el riesgo es mínimo.

     firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="xx.xx.xx.xx" accept' 

    Deberá ajustar la zona si usa algo diferente. También solo haría esto para clientes internos de IPv4 en una LAN.

    Fuente: https://access.networkinghat.com/solutions/1587673

    Ya hay una plantilla de service disponible:

     firewall-cmd --add-service=mdns # runtime firewall-cmd --permanent --add-service=mdns # permanent 

    tal vez necesites instalar firewalld-config-workstation .

    Si todavía no lo haces funcionar. ¿Podría agregar la regla a su pregunta? Ej. Con:

     iptables-save | grep ' 5353 ' 

    o tal vez solo intente:

     firewall-cmd --remove-service=mdns firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW,RELATED -j ACCEPT