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한 번에 하나의 앱 인스턴스만 실행할 수 있을 것입니다..

많은 데스크탑 또는 소규모 로컬 네트워크 박스용 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은 두 가지 방법을 권장합니다.

해결 방법 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나를 위해 작동합니다.

관련 정보