Firewalldは、一時ポートからのマルチキャストDNSクエリ応答を許可します。

Firewalldは、一時ポートからのマルチキャストDNSクエリ応答を許可します。

一時UDPソースポートを使用して、クライアントアプリケーションからマルチキャストターゲットに送信されたMDNSクエリに応答するようにFirewalld(Fedora 21)を設定しようとしています。応答はユニキャストです。順序は次のとおりです(wiresharkを使用してキャプチャ)。

  1. UDP:ローカルアドレス:45325(一時) - > 224.0.0.251:5353クエリ
  2. UDP:一部のシステム:5353 - >ローカルアドレス:45325;
  3. ICMP:ローカルアドレス - >一部のシステム:タイプ:3(ターゲットに接続できません)、コード:10(ホスト管理によって禁止)

ポート5353 UDPを追加してFirewalld mdnsサービスを有効にしましたが、応答には役立ちませんでした。

どんなアドバイスも本当にありがとうございます。

答え1

おめでとうございます。パケットフィルタリングの概念の限界を発見しました。マルチキャストプロトコル追跡:転送は絶対に禁止されているため、同じアドレスから応答を返すことはできません。~からマルチキャストアドレス。ファイアウォールがお客様のリクエストに対するレスポンスを一致させずにブロックしました。明らかに、システムMDNSデーモンavahiは固定ポート5353から送信してそれを防ぐので、そのポートでも応答を受け取ります。ファイアウォールルールは、特にポート5353を許可します。できればソフトウェアにavahiと会話させる、これはavahiが推奨するソリューションです。

または、デフォルトのavahiオプションを使用できますdisallow-other-stacks=no固定ポート 5353 を使用するようにクライアントアプリケーションを構成する。これがAvahiの信頼性にどのような影響を与えるかは不明です。あるいは、必要でない場合は、単にAvahiを無効にすることもできます。もちろん、アプリケーションが許可する場合選ぶ固定ソースポートをファイアウォールに追加するだけで機能します。

...「クライアントアプリケーション」と言わない限り、理論的には複数のインスタンスを同時に実行できるソフトウェアクラスを意味します。単一デーモンを介してすべてのネットワーク要求を実行するわけではありません。そしてこのアプリはavahiが実装したSO_REUSEPORTハッキングを使用しないため、disallow-other-stacks=no一度に1つのアプリインスタンスしか実行できません。

多くのデスクトップまたは小規模ローカルネットワークボックス用のLinuxソフトウェアは、ホストファイアウォールで実行するように設計されていない可能性があります。 Fedoraはそのための基本的なディストリビューションです。 Fedora Workstationは最近、ファイアウォールのデフォルト領域を「FedoraWorkstation」に変更し、1024以上のすべてのTCPまたはUDPポートへの接続を許可しました。 Fedora Workstationが構成されているかファイアウォールがなくても、ソフトウェアは変更なく実行できます。

Firewalldなどのホストファイアウォールの重要性を表現するのは難しいです。 Shorewallなどのゾーン間ルーティングはサポートされていません。プライマリゾーンをより制限的なゾーンに設定することを選択して、ホームワイヤレスネットワークまたはVPNのより多くの許可設定を提供できます。 NetworkManagerを一生懸命使用すると、家庭用有線ネットワークでも機能するようになります。ただし、デフォルトでは有効になっている機能と比較して、あまりにもあいまいです。

操作は完全に安全です基本ファイアウォールなしでFedora(またはUbuntu)をインストールします。あなたが放棄するのは、ポートを開く中央集中型のポリシーです。後でランダムなソフトウェアを設定し、ポートでリッスンしたいことに気付かなかった場合に備えてください。

人々はLinuxとWindowsのファイアウォールを比較しようとしますが、Firewalldとは異なり、Windowsファイアウォールは明らかに必要であり、実際には一般の人が理解することができます。。 Windowsはデフォルトでポートを開き、ホストファイアウォールを使用してポートを保護します。有線ネットワークに対して信頼できる/信頼できない領域を実装します。新しいネットワークはデフォルトでは信頼できず、変更するかどうかを尋ねるポップアップが表示されます。さまざまな有線ネットワークは、DHCP サーバーの MAC アドレスで識別されます。少なくともWindows 8以降、「express」を初めて実行すると、現在のネットワークが信頼できるとマークされます。これは理論的には迷惑ですが、実際には非常に役立ちます。

技術的には、dbusを介してFirewalldと通信し、それに応答してバインドされた一時ポートを開くように要求できるようにソフトウェアを変更することもできます。しかし、なんか私はこれが役に立つ提案だとは思わない。

答え2

すでに利用可能なサービステンプレートがあります。

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

たぶんあなたはそれをインストールする必要がありますfirewalld-config-workstation

それでも動作しない場合。質問にルールを追加してもよろしいですか?たとえば、

iptables-save | grep ' 5353 '

またはそれを試してみてください:

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

答え3

サーバーに接続されているいくつかの特定のデバイスで同じ問題が発生します。どんなに努力しても、ファイアウォールは要求をブロックします。

知識ベースによると、Redhatは2つの方法をお勧めします。

解決策1:

着信トラフィックのUDPポートを開きます。

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

サービスがUDP 5353を開いているため、これはうまくいかない可能性がありmdns、これは役に立たないと述べました。

解決策2:

サービスの作成:

<?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>

しかし、この例は着信ではなく発信のようです。代わりに切り替えを試して、役に立つ<destination><source address="xx.xx.xx.xx">どうかを確認できます。

解決策3:

個人的にはどちらも機能しません。最後に、デフォルトでは、すべてのポートの送信元IPをホワイトリストに追加しました。私はこれをお勧めしませんが、ファイアウォールの操作に数時間を費やすのに疲れており、問題のクライアントはプライベートLANのRaspberry Piデバイスであるため、リスクは最小限に抑えられます。

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

他のものを使用する場合は、領域を調整する必要があります。また、LANの内部IPv4クライアントに対してのみこれを行います。

源泉:https://access.redhat.com/solutions/1587673

答え4

Fedora 29では、mdnsが私のLANでデフォルトで機能しないという問題があります(avahiとnss-mdnsをインストールした後にのみ)。 firewall-cmd --permanent --add-service=mdns私のために動作します。

関連情報