☰

Depuración de resolución de nombres con Windows y APIPA

tag-icon • tag-icon windows ip hostname mdns zeroconf
Depuración de resolución de nombres con Windows y APIPA

Para equipos de laboratorio uso la configuración predeterminada en todas partes y ellos usanconfiguración automática de ip(Creo que APIPA también conocido como zeroconf); Los puse en un interruptor privado.

Siempre pude comunicarme con ellos a través de su nombre de host, creo que esto funciona a través de mDNS.

Ahora reemplacé un dispositivo por uno idéntico y de repente esto dejó de funcionar:

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

Seguramente los instrumentos están activos y el nombre de host definitivamente es correcto:

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

Cuál podría ser la razón para eso? ¿El problema es el "anfitrión" o el "cliente"? ¿Cómo puedo depurar esto?

Respuesta1

La resolución de nombres locales puede utilizar varios protocolos. Agrupados por sistema operativo cliente:

  • Windows 10 (no estoy seguro de qué versiones, peroaproximadamente10.1803 o posterior) son compatibles con ApplemDNSprotocolo (multidifusión UDP al puerto 5353). Las consultas de nombres se envían a los grupos de multidifusión 224.0.0.251 y FF02::FB. Esto no depende de la configuración IP (a pesar de ser parte de la suite Zeroconf no usa ni implica APIPA ni viceversa). Élapareceestar activo siempre que LLMNR esté activo.

    (Si tiene instalado iTunes, independientemente de la versión de Windows, instala su propio cliente mDNS, Apple Bonjour, como LSP de Winsock. Bonjour solo resuelve nombres con el .localsufijo, mientras que el cliente integrado acepta nombres sin TLD de etiqueta única como Bueno.)

  • Windows Vista y Server 2008 y posteriores admiten laLLMNRprotocolo (multidifusión UDP al puerto 5355). Las consultas de nombres se envían a los grupos de multidifusión 224.0.0.252 y FF02::1:3. Esto no depende de la configuración de IP; está activo mientras Network Discovery esté activo.

  • Todas las versiones de Windows soportan elServicio de nombres NetBIOSprotocolo (difusión UDP/IPv4 al puerto 137, así como algunoscomplejoelección de "navegador maestro"). Según tengo entendido, las consultas de nombres se transmiten. Esto no depende de la configuración de IP, pero sí requiere que SMBv1 esté instalado y habilitado.

No sé qué "equipo de laboratorio" usas, pero cualquiera de esos protocolospodríaser compatible con dispositivos que no sean Windows. (Por ejemplo, en Linux, mDNS se implementa mediante Avahi o mDNSResponder; LLMNR se implementa mediante systemd-resolved o xllmnrd; NBNS se implementa mediante Samba nmbd). Muchos dispositivos hablan mDNS. Los impresores tienden a hablar los tres y más.

Cómo solucionar problemas de los protocolos basados ​​en multidifusión:

  1. Instalar unherramienta de captura de paquetes.
  2. Apuntelo a su interfaz LAN.
  3. Intente resolver un nombre, vea si su computadora genera los paquetes de consulta LLMNR o mDNS esperados y si el otro dispositivo genera alguna respuesta.
  4. Reinicie el otro dispositivo (o simplemente vuelva a conectarlo a la red) y vea si ese dispositivo anuncia su propio nombre.registropaquetes.

Tenga en cuenta que nslookupesnouna herramienta de búsqueda de nombres generales. Esestrictamenteun cliente DNS de unidifusión y no ayuda en absoluto con mDNS/LLMNR/NBNS.

información relacionada