Hostname.local kann im LAN nicht aufgelöst werden

Hostname.local kann im LAN nicht aufgelöst werden

Früher konnte ich zwischen Maschinen in meinem LAN kommunizieren, aber das funktioniert nicht mehr. Ich kann natürlich über die IP per SSH kommunizieren, aber es ist DHCP, also kann es sich von Zeit zu Zeit ändern. Auf beiden Maschinen läuft Debian 9.12, eine ist eine VM in einem Windows-Host, aber es hat trotzdem funktioniert; ich habe nicht mit den Konfigurationsdateien herumgespielt, nur regelmäßige Updates.ssh [email protected]

ping hostname.local
ping: hostname.local: Name or service not known

(es ist möglicherweise nicht genau diese Nachricht, da ich sie aus dem Französischen übersetze)

ssh hostname.local
ssh: Could not resolve hostname hostname.local: Name or service not known

(SSH-Ausgaben auf Englisch)

Von avahi.org:

Avahi ist ein System, das die Diensterkennung in einem lokalen Netzwerk über die mDNS/DNS-SD-Protokollsuite erleichtert.

Ich habe mir das angesehen /etc/resolv.conf, /etc/avahi/avahi-daemon.confaber /etc/nsswitch.confes ist die Standardkonfiguration.

/etc/resolv.conf(wird bei network-managerjedem Start zurückgesetzt)

# Generated by NetworkManager
search lan
nameserver xx.xx.xx.xx # DNS IPs obtained from DHCP
nameserver xx.xx.xx.xx 

man resolv.confbesagt, dass die searchListe standardmäßig nur den lokalen Domänennamen enthält (so in etwa habe ich es aus der Manpage auf Französisch übersetzt). Sollte es nicht localstattdessen heißen lan?

Ich habe versucht, es zu ändern und sofort einen anderen Host in meinem LAN anzupingen oder per SSH zu kontaktieren (ohne den Netzwerkmanager neu zu starten), aber es hat nicht funktioniert. Und wenn ich den Netzwerkmanager neu starte, schreibt /etc/resolv.confund setzt er search lan.

/etc/nsswitch.conf(Standard, ich habe keine Änderung vorgenommen)

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

avahi-browseIch habe versucht, mit und Hosts und Dienste zu entdecken nbtscan, die auf Avahi (Zeroconf/Bonjour) basieren, aber sie scheinen nur den Host zu finden, auf dem sie ausgeführt werden.

(Ich weiß, dass dies möglicherweise ein Duplikat anderer Fragen ist, aber ich habe keine Antwort gefunden und mein Ruf reicht nicht aus, um etwas zu unternehmen.)

Antwort1

Fand es !

Es scheint, dass mein Router tatsächlich einen DNS-Server hat:

nslookup host_ip router_ip
Server:     192.168.1.254
Address:    192.168.1.254#53

69.1.168.192.in-addr.arpa   name = hostname.lan.

Damit ist die Frage .local„Vs.“ beantwortet .lan.Im aktuellen Debian ist die lokale Domäne .lan.

Gibt dennoch ping hostname.laneinen unbekannten Host zurück.

Dank anhttps://askubuntu.com/questions/623940/network-manager-how-to-stop-nm-updating-etc-resolv-conf, ich fand heraus, dass es /etc/resolv.confsich um einen Symlink zu handelt /var/run/NetworkManager/resolv.conf; also musste ichdurch mein eigenes ersetzenresolv.conf:

search lan
nameserver 192.168.1.254

sodass der DNS des Routers verwendet wird (der die Abfragen bei Bedarf weiterleitet).

Netzwerk-Manager neu starten systemctl restart network-managerund es funktioniert wie am Schnürchen:

$ ping hostname.lan
PING hostname.lan (192.168.1.69) 56(84) bytes of data.
64 bytes from hostname.lan (192.168.1.69): icmp_seq=1 ttl=64 time=2.02 ms

( ping google.frum sicherzustellen, dass WAN-Anfragen verarbeitet werden)

Antwort2

In meinem Fall lag der Grund dafür, dass ein bestimmter Host im Netzwerk über das Präfix .local nicht erreichbar war, einfach darin, dass der Avahi-Daemon-Dienst auf diesem Host gestoppt worden war:

[~][0]$ service avahi-daemon status
○ avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ○ avahi-daemon.socket
[~][3]$ service avahi-daemon start
[~][0]$ 
█[~][0]$ ping asus.local
PING asus.local (192.168.1.204) 56(84) bytes of data.
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=1 ttl=64 time=0.892 ms
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=2 ttl=64 time=0.848 ms
64 bytes from 192.168.1.204 (192.168.1.204): icmp_seq=3 ttl=64 time=0.784 ms
^C

Antwort3

Sie benötigen keinen FQDN. Verwenden Sie einfach den Host-Teil. Beispiel:

`[root@darouter ~]# arping -I enp2s0f1 matilda
ARPING 192.168.100.12 from 192.168.100.254 enp2s0f1
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.759ms
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.801ms
Unicast reply from 192.168.100.12 [D0:67:E5:EB:37:25]  0.732ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)`

Ich habe Arping verwendet, da Matilda eine Windoz-Box ist. Das war einfacher, als herauszufinden, wie man eingehende Pings zulässt. Ich würde DNS auf dem Router deaktivieren. DortsollenHier können Sie die IP-Adresse eines DNS-Servers eingeben, damit Sie Ihren internen DNS verwenden können. Wenn Ihr interner DNS nicht nach Hostnamen aufgelöst wird, müssen Sie herausfinden, wo Ihre DNS-Konfiguration defekt ist. Ich hatte dieses Problem vor einiger Zeit. Leider ist das schon eine Weile her; und da ich mich nicht daran erinnere, was ich gestern gemacht habe, kann ich Ihnen keine definitive Antwort darauf geben, was ich getan habe, um es zu lösen.

Hoffe das hilft!

Todh

verwandte Informationen