☰

Debuggen der Namensauflösung mit Windows und APIPA

tag-icon • tag-icon windows ip hostname mdns zeroconf
Debuggen der Namensauflösung mit Windows und APIPA

Für Laborgeräte verwende ich überall Standardeinstellungen und sie verwendenAutomatische IP-Konfiguration(APIPA, auch bekannt als Zeroconf, glaube ich); ich habe sie auf einen privaten Switch gelegt.

Ich konnte sie immer über ihren Hostnamen ansprechen, ich denke, das funktioniert über mDNS.

Nun habe ich ein Gerät durch ein baugleiches ersetzt und plötzlich funktionierte dies nicht mehr:

C:\>ping FSW26-101414
Ping request could not find host FSW26-101414. Please check the name and try aga
in.

Das Gerät ist auf jeden Fall aktiv und der Hostname auf jeden Fall korrekt:

C:\>ping 169.254.27.85

Pinging 169.254.27.85 with 32 bytes of data:
Reply from 169.254.27.85: bytes=32 time<1ms TTL=128
Reply from 169.254.27.85: bytes=32 time<1ms TTL=128
Reply from 169.254.27.85: bytes=32 time<1ms TTL=128
Reply from 169.254.27.85: bytes=32 time<1ms TTL=128

Ping statistics for 169.254.27.85:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Was könnte der Grund dafür sein? Liegt das Problem am „Host“ oder am „Client“? Wie kann ich das debuggen?

Antwort1

Die lokale Namensauflösung kann mehrere Protokolle verwenden. Gruppiert nach Client-Betriebssystem:

  • Windows 10 (nicht sicher, welche Versionen, aberetwa10.1803 oder höher) unterstützen die ApplemDNSProtokoll (UDP-Multicast an Port 5353). Namensabfragen werden an die Multicast-Gruppen 224.0.0.251 und FF02::FB gesendet. Dies hängt nicht von der IP-Konfiguration ab (obwohl es Teil der Zeroconf-Suite ist, verwendet oder impliziert es weder APIPA noch umgekehrt). Eserscheintsoll immer aktiv sein, wenn LLMNR aktiv ist.

    (Wenn Sie iTunes installiert haben, wird unabhängig von der Windows-Version ein eigener mDNS-Client – ​​Apple Bonjour – als Winsock-LSP installiert. Bonjour löst nur Namen mit dem .localSuffix auf, während der integrierte Client auch Namen mit einem Label und ohne TLD akzeptiert.)

  • Windows Vista und Server 2008 und höher unterstützen dieLLMNRProtokoll (UDP-Multicast an Port 5355). Namensabfragen werden an die Multicast-Gruppen 224.0.0.252 und FF02::1:3 gesendet. Dies hängt nicht von der IP-Konfiguration ab; es ist aktiv, solange die Netzwerkerkennung aktiv ist.

  • Alle Windows-Versionen unterstützen dieNetBIOS-NamensdienstProtokoll (UDP/IPv4 Broadcast an Port 137, sowie einigeKomplex"Master-Browser"-Wahl). Soweit ich es verstehe, werden Namensabfragen gesendet. Dies hängt nicht von der IP-Konfiguration ab, erfordert aber die Installation und Aktivierung von SMBv1.

Ich weiß nicht, welche "Laborausrüstung" Sie verwenden, aber jedes dieser Protokollekönntevon Nicht-Windows-Geräten unterstützt werden. (Beispielsweise wird mDNS unter Linux von Avahi oder mDNSResponder implementiert; LLMNR wird von systemd-resolved oder xllmnrd implementiert; NBNS wird von Samba nmbd implementiert.) Viele Geräte sprechen mDNS. Drucker sprechen in der Regel alle drei und mehr.

So beheben Sie Probleme mit den Multicast-basierten Protokollen:

  1. Installieren SieTool zur Paketerfassung.
  2. Richten Sie es auf Ihre LAN-Schnittstelle.
  3. Versuchen Sie, einen Namen aufzulösen, und prüfen Sie, ob Ihr Computer die erwarteten LLMNR- oder mDNS-Abfragepakete generiert und ob das andere Gerät Antworten generiert.
  4. Starten Sie das andere Gerät neu (oder verbinden Sie es einfach erneut mit dem Netzwerk) und prüfen Sie, ob das Gerät seinen eigenen Namen ankündigtAnmeldungPakete.

Beachten Sie, nslookupdassnichtein allgemeines Namenssuchtool. Es iststrengein Unicast-DNS-Client und hilft überhaupt nicht bei mDNS/LLMNR/NBNS.

verwandte Informationen