☰

Отладка разрешения имен с помощью Windows и APIPA

tag-icon • tag-icon windows ip hostname mdns zeroconf
Отладка разрешения имен с помощью Windows и APIPA

Для лабораторного оборудования я везде использую настройки по умолчанию, и они используютавтоматическая конфигурация IP(APIPA он же zeroconf, я думаю); Я поместил их на частный коммутатор.

Мне всегда удавалось обратиться к ним по имени хоста, думаю, это работает через mDNS.

Теперь я заменил одно устройство на такое же, и вдруг это перестало работать:

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

Инструменты, безусловно, работают, и имя хоста определенно верное:

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

В чем может быть причина? Проблема в "хосте" или "клиенте"? Как это можно отладить?

решение1

Локальное разрешение имен может использовать несколько протоколов. Сгруппировано по клиентской ОС:

  • Windows 10 (не уверен, какие именно версии, нопримерно10.1803 или более поздняя версия) поддерживают ApplemDNSпротокол (UDP multicast на порт 5353). Запросы имени отправляются в multicast-группы 224.0.0.251 и FF02::FB. Это не зависит от конфигурации IP (несмотря на то, что это часть пакета Zeroconf, он не использует и не подразумевает APIPA и наоборот). Этопоявляетсябыть активным всегда, когда активен LLMNR.

    (Если у вас установлен iTunes, независимо от версии Windows он устанавливает собственный клиент mDNS — Apple Bonjour — как Winsock LSP. Bonjour разрешает только имена с суффиксом .local, тогда как встроенный клиент также принимает однокомпонентные имена без TLD.)

  • Windows Vista и Server 2008 и более поздние версии поддерживаютLLMNRПротокол (UDP multicast на порт 5355). Запросы имени отправляются в multicast-группы 224.0.0.252 и FF02::1:3. Это не зависит от конфигурации IP; это активно, пока активно Network Discovery.

  • Все версии Windows поддерживаютСлужба имен NetBIOSпротокол (вещание UDP/IPv4 на порт 137, а также некоторыесложныйВыборы "главного браузера"). Насколько я понимаю, запросы имен транслируются. Это не зависит от конфигурации IP, но требует установки и включения SMBv1.

Я не знаю, какое «лабораторное оборудование» вы используете, но любой из этих протоколовмощьподдерживаться не-Windows-устройствами. (Например, в Linux mDNS реализуется Avahi или mDNSResponder; LLMNR реализуется systemd-resolved или xllmnrd; NBNS реализуется Samba nmbd.) Многие устройства говорят на mDNS. Принтеры, как правило, говорят на всех трех и более.

Как устранить неполадки многоадресных протоколов:

  1. Установитьинструмент захвата пакетов.
  2. Направьте его на интерфейс локальной сети.
  3. Попробуйте разрешить имя, посмотрите, генерирует ли ваш компьютер ожидаемые пакеты запросов LLMNR или mDNS и генерирует ли другое устройство какие-либо ответы.
  4. Перезагрузите другое устройство (или просто переподключите его к сети) и посмотрите, объявит ли это устройство свое имя.Регистрацияпакеты.

Обратите внимание, что nslookupэтонетобщий инструмент поиска имени. Этострогоодноадресный DNS-клиент, который вообще не помогает с mDNS/LLMNR/NBNS.

Связанный контент