Linux systemd-resolved не отвечает на MulticastDNS

Вопрос или проблема

В общем, в настоящее время я заменяю все сетевые настройки встроенными средствами systemd. NetworkManager, dnsmasq, dhcpcd, avahi-daemon — все исключено, и, похоже, все в основном работает.

За исключением того, что локальные имена хостов больше не разрешаются с моего настольного компьютера:

C:\Users\Christian>ping fritzwlan
Запрос Ping не мог найти хост fritzwlan. Пожалуйста, проверьте имя и попробуйте снова.

Теперь я вижу запросы на сервере:

root@gatekeeper:/home/stieber# tcpdump -i lan -p udp
...
15:27:18.381225 IP Desktop.mdns > mdns.mcast.net.mdns: 0 A (QM)? fritzwlan.local. (33)
15:27:18.381506 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:18.469278 IP gatekeeper.mdns > mdns.mcast.net.mdns: 0 PTR (QM)? 255.255.1.10.in-addr.arpa. (43)
15:27:18.804129 IP Desktop.61938 > 224.0.0.252.5355: UDP, длина 27
15:27:18.804129 IP Desktop.61316 > 224.0.0.252.5355: UDP, длина 27
15:27:19.131294 IP Desktop.netbios-ns > 10.1.255.255.netbios-ns: UDP, длина 50
15:27:19.383976 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:19.384990 IP Desktop.mdns > mdns.mcast.net.mdns: 0 A (QM)? fritzwlan.local. (33)
15:27:19.385926 IP Desktop.mdns > mdns.mcast.net.mdns: 0 AAAA (QM)? fritzwlan.local. (33)
15:27:19.610547 IP gatekeeper.mdns > mdns.mcast.net.mdns: 0 PTR (QM)? 255.255.1.10.in-addr.arpa. (43)

/var/log/syslog ничего не показывает.

Насколько я могу судить, systemd-resolved должен иметь включенный мультикаст:

root@gatekeeper:/home/stieber# resolvectl status
Global
          Протоколы: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
   resolv.conf режим: stub
Резервные DNS-серверы 8.8.8.8 1.1.1.1

Link 2 (lan)
    Текущие области: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Протоколы: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wan)
...

и

root@gatekeeper:/home/stieber# resolvectl mdns
Global: yes
Link 2 (lan): yes
...
root@gatekeeper:/home/stieber# resolvectl llmnr
Global: yes
Link 2 (lan): yes
...

Конфигурационный файл также говорит, что все полностью включено, а не только resolve:

root@gatekeeper:/home/stieber# cat /etc/systemd/resolved.conf
...
# много удаленных комментариев
...
[Resolve]
FallbackDNS=8.8.8.8 1.1.1.1
DNSStubListenerExtra=10.1.1.1:53
DNSStubListenerExtra=127.0.0.1:53
LLMNR=true
MulticastDNS=true

Это не самая ужасная проблема, особенно поскольку внешние хосты разрешаются нормально, так что «интернет» работает.

На самом сервере он разрешается нормально:

root@gatekeeper:/home/stieber# dig fritzwlan

; <<>> DiG 9.18.24-1-Raspbian <<>> fritzwlan
;; глобальные параметры: +cmd
;; Получен ответ:
;; ->>HEADER<<- команда: QUERY, статус: NOERROR, id: 47502
;; флаги: qr aa rd ra ad; ЗАПРОС: 1, ОТВЕТ: 1, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНЫЙ: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флаги:; udp: 65494
;; СЕКЦИЯ ВОПРОСА:
;fritzwlan.                     IN      A

;; СЕКЦИЯ ОТВЕТА:
fritzwlan.              0       IN      A       10.1.1.2

;; Время запроса: 0 мс
;; СЕРВЕР: 127.0.0.53#53(127.0.0.53) (UDP)
;; КОГДА: Вск. 05 Май 15:44:02 CEST 2024
;; РАЗМЕР MSG  получен: 54

Мультикаст также включен на интерфейсе:

[Match]
Name=lan

[Link]
Multicast=true

[Network]
Address=10.1.1.1/16
DHCPServer=yes
MulticastDNS=true
LLMNR=true

[DHCPServer]
...

Основываясь на комментариях:

root@gatekeeper:/home/stieber# ss -lpn 'sport = :5353 or sport = :5355'
Netid             State              Recv-Q             Send-Q                         Local Address:Port                          Peer Address:Port             Process
udp               UNCONN             0                  0                                    0.0.0.0:5353                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=15))
udp               UNCONN             0                  0                                    0.0.0.0:5355                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=11))
udp               UNCONN             0                  0                                          *:5353                                     *:*                 users:(("systemd-resolve",pid=1626,fd=16))
udp               UNCONN             0                  0                                          *:5355                                     *:*                 users:(("systemd-resolve",pid=1626,fd=13))
tcp               LISTEN             0                  4096                                 0.0.0.0:5355                               0.0.0.0:*                 users:(("systemd-resolve",pid=1626,fd=12))
tcp               LISTEN             0                  4096                                    [::]:5355                                  [::]:*                 users:(("systemd-resolve",pid=1626,fd=14))

Так что, похоже, он слушает на этих портах. Не знаю, как «мультикаст» играет в этом ключевую роль.

То же самое с брандмауэром: по отношению к «LAN» он должен быть полностью открыт:

root@gatekeeper:/home/stieber# nft list ruleset
        chain output-rejects {
                oifname "wan" tcp dport { 25, 110, 143 } reject
        }

        chain output {
                type filter hook output priority 100; policy accept;
                jump output-rejects
        }
...
table inet filter {
...
        chain input {
                type filter hook input priority filter; policy drop;
                ct state invalid drop
                icmp type echo-request limit rate over 2/second drop
                ip protocol icmp accept
                iif { "lo", "lan" } accept
...

Но, должен признаться, я еще не знаю, как мультикаст учитывается в этом…


Так что сейчас я довольно сбит с толку, куда смотреть… есть какие-нибудь идеи?

Я столкнулся с той же проблемой, т.е. Linux-устройство не отвечало на запросы mDNS. Это не должно иметь значения, но в файле /etc/systemd/resolved.conf я установил DNSSEC=no в разделе [Resolve]. Это не должно повлиять на разрешение mdns, но когда я установил это и перезапустил сервис, он сразу же начал отвечать на запросы.

Ответ или решение

Ваша проблема с отсутствием ответов на запросы MulticastDNS от systemd-resolved может быть вызвана несколькими факторами. Давайте изучим некоторые ключевые моменты.

1. Настройки systemd-resolved

Судя по вашим выводам, ваша конфигурация systemd-resolved выглядит корректной, и multicast DNS должен быть включен:

[Resolve]
FallbackDNS=8.8.8.8 1.1.1.1
LLMNR=true
MulticastDNS=true

Тем не менее, убедитесь, что настройки без лишних пробелов и комментариев, так как иногда это может вызывать проблемы. Попробуйте ясно задать ключи DNSSEC=no, LLMNR=true и MulticastDNS=true, как вы уже сделали.

2. Система потоков

Проверьте, правильно ли запущен systemd-resolved. Вы можете использовать команду:

systemctl status systemd-resolved

Если служба остановлена или не активна, запустите её:

sudo systemctl start systemd-resolved
sudo systemctl enable systemd-resolved

3. Firewall

Проверьте настройки firewall. Хотя вы отметили, что через nftables у вас нет блокировок, все же убедитесь, что порты 5353 (mDNS) и 5355 (LLMNR) открыты для входящих запросов. Для проверки настройки можно использовать:

sudo nft list ruleset

Если вы используете iptables, проверьте аналогично.

4. Проверка Multicast

Вы можете использовать утилиты ping и tcpdump для тестирования multicast:

ping 224.0.0.251  # для mDNS

Или мониторинг mDNS-трафика:

sudo tcpdump -i <интерфейс> -p udp port 5353

5. Использование DNS

Возможно, настройка resolv.conf не соответствует ожидаемому поведению. Обратите внимание на следующее:

cat /etc/resolv.conf

Убедитесь, что там указаны правильные адреса, и система отправляет запросы на правильные локальные DNS-серверы.

6. Перезагрузка служб

После всех изменений всегда перезагружайте службы или перезагружайте систему, чтобы изменения вступили в силу:

sudo systemctl restart systemd-resolved

Заключительные шаги

После выполнения всех этих действий попробуйте снова проверить разрешение имен:

ping fritzwlan.local

Если проблема сохраняется, вы можете попробовать заменить systemd-resolved на другую службу mDNS, такую как avahi-daemon, которая может лучше справляться с определенными запросами mDNS.

Если никаких изменений не произошло, попробуйте сделать экспорт конфигурации и запустить systemd-resolved в отладочном режиме, чтобы получить больше информации о том, что происходит в момент запроса mDNS.

Оцените материал
Добавить комментарий

Капча загружается...