Depurando a resolução de nomes com o Windows e o APIPA

Question

Para equipamentos de laboratório, eu uso configurações padrão em todos os lugares e eles usam configuração automática de IP (APIPA aka zeroconf, eu acho); Eu os coloquei em um interruptor privado.

Eu sempre fui capaz de endereçá-los através do nome do host, acho que isso funciona via mDNS.

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

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

Os instrumentos estão com segurança 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 o motivo disso? O problema é o "host" ou o "cliente"? Como posso depurar isso?

    

Answer 1

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

• O Windows 10 (não tenho certeza de quais versões, mas aproximadamente 10.1803 ou posterior) suportam o mDNS da Apple (multicast UDP para a porta 5353). As consultas de nome são enviadas para os grupos multicast 224.0.0.251 e FF02 :: FB. Isso não depende da configuração IP (apesar de fazer parte do conjunto Zeroconf, não usa nem implica APIPA nem vice-versa). Ele aparece para estar ativo sempre que o LLMNR estiver ativo.

  (Se você tem o iTunes instalado, independentemente da versão do Windows, ele instala seu próprio cliente mDNS - Apple Bonjour - como um Winsock LSP. O Bonjour só resolve nomes com o sufixo .local , enquanto o cliente interno aceita rotular nomes sem TLDs também.)

• O Windows Vista e o Server 2008 e versões posteriores suportam o protocolo LLMNR (multidifusão UDP para a porta 5355) . As consultas de nome são enviadas para os grupos multicast 224.0.0.252 e FF02 :: 1: 3. Isso não depende da configuração do IP; está ativo enquanto a Descoberta de Rede estiver ativa.

• Todas as versões do Windows suportam o protocolo NetBIOS Name Service (transmissão UDP / IPv4 para a porta 137, bem como alguma eleição de "browser principal" complexo . Tanto quanto eu entendo, as consultas de nome são transmitidas. Isso não depende da configuração de IP, mas exige que o SMBv1 seja instalado e ativado.

Eu não sei qual "equipamento de laboratório" você usa, mas qualquer um desses protocolos pode ser suportado por dispositivos não-Windows. (Por exemplo, no Linux, o mDNS é implementado pelo Avahi ou mDNSResponder; o LLMNR é implementado pelo systemd-resolved ou pelo xllmnrd; o NBNS é implementado pelo Samba nmbd.) Muitos dispositivos falam mDNS. Impressoras tendem a falar todos os três e mais.

Como solucionar os protocolos baseados em multicast:

1. Instale uma ferramenta de captura de pacotes .
2. Aponte para a interface da sua 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 respostas.
4. Reinicialize o outro dispositivo (ou apenas reconecte-o à rede) e veja se esse dispositivo anuncia seu próprio nome registro pacotes.

Observe que nslookup não é uma ferramenta de pesquisa de nome geral. É estritamente um cliente DNS unicast e não ajuda em nada com mDNS / LLMNR / NBNS.