☰

Depurando resolução de nomes com Windows e APIPA

tag-icon • tag-icon windows ip hostname mdns zeroconf
Depurando resolução de nomes com Windows e APIPA

Para equipamentos de laboratório eu uso configurações padrão em todos os lugares e eles usamConfiguração automática de IP(APIPA também conhecido como zeroconf, eu acho); Eu os coloquei em um switch privado.

Sempre consegui abordá-los através do nome do host, acho que isso funciona via mDNS.

Agora substituí um dispositivo por outro idêntico e de repente parou de funcionar:

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

As ferramentas certamente estão ativas e o nome do host definitivamente correto:

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

Qual poderia ser a razão para isso? O problema é o "host" ou o "cliente"? Como posso depurar isso?

Responder1

A resolução de nomes locais pode usar vários protocolos. Agrupados por sistema operacional cliente:

  • Windows 10 (não tenho certeza de quais versões, masaproximadamente10.1803 ou posterior) suportam o ApplemDNSprotocolo (multicast UDP para a porta 5353). As consultas de nomes são enviadas para os grupos multicast 224.0.0.251 e FF02::FB. Isto não depende da configuração do IP (apesar de fazer parte da suíte Zeroconf não utiliza nem implica APIPA nem vice-versa). Istoparecepara estar ativo sempre que o LLMNR estiver ativo.

    (Se você tiver o iTunes instalado, independentemente da versão do Windows, ele instala seu próprio cliente mDNS – Apple Bonjour – como um LSP Winsock. O Bonjour resolve apenas nomes com o .localsufixo, enquanto o cliente integrado aceita nomes sem TLD de rótulo único como bem.)

  • O Windows Vista e o Server 2008 e posteriores suportam oLLMNRprotocolo (multicast UDP para a porta 5355). As consultas de nomes são enviadas para grupos multicast 224.0.0.252 e FF02::1:3. Isto não depende da configuração do IP; ele estará ativo enquanto o Network Discovery estiver ativo.

  • Todas as versões do Windows suportam oServiço de nomes NetBIOSprotocolo (transmissão UDP/IPv4 para a porta 137, bem como algunscomplexoeleição do "navegador mestre"). Pelo que entendi, as consultas de nomes são transmitidas. Isso não depende da configuração do IP, mas exige que o SMBv1 esteja instalado e habilitado.

Não sei que “equipamento de laboratório” você usa, mas qualquer um desses protocolospoderser compatível com dispositivos não Windows. (Por exemplo, no Linux, o mDNS é implementado pelo Avahi ou mDNSResponder; o LLMNR é implementado pelo systemd-resolved ou xllmnrd; o NBNS é implementado pelo Samba nmbd.) Muitos dispositivos falam mDNS. As impressoras tendem a falar todos os três e mais.

Como solucionar problemas de protocolos baseados em multicast:

  1. Instale umferramenta de captura de pacotes.
  2. Aponte-o para sua interface LAN.
  3. Tente resolver um nome, veja se o seu computador gera os pacotes de consulta LLMNR ou mDNS esperados e se o outro dispositivo gera alguma resposta.
  4. Reinicie o outro dispositivo (ou apenas reconecte-o à rede) e veja se esse dispositivo anuncia seu próprio nomecadastropacotes.

Observe que nslookupénãouma ferramenta geral de pesquisa de nomes. Isso éestritamenteum cliente DNS unicast e não ajuda em nada com mDNS/LLMNR/NBNS.

informação relacionada