Вопрос или проблема
В общем, в настоящее время я заменяю все сетевые настройки встроенными средствами 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.