Skip to main content

Проблема с локальным резолвингом в сети ОТ

Пошаговый чек-лист

Шаг 1. Зафиксировать состояние обоих ПК

На рабочем и нерабочем ПК выполнить:

hostname
ipconfig /all
route print
arp -a
ipconfig /displaydns
nbtstat -n
nbtstat -c
netsh interface ipv6 show addresses
netsh interface ipv6 show neighbors

Сохрани вывод в файлы, чтобы потом сравнить.

Например:

ipconfig /all > C:\diag_ipconfig.txt
route print > C:\diag_route.txt
arp -a > C:\diag_arp.txt
ipconfig /displaydns > C:\diag_dns_cache.txt
nbtstat -n > C:\diag_nbt_local.txt
nbtstat -c > C:\diag_nbt_cache.txt
netsh interface ipv6 show addresses > C:\diag_ipv6_addr.txt
netsh interface ipv6 show neighbors > C:\diag_ipv6_nei.txt

Шаг 2. Проверить резолв до очистки кэшей

На обоих ПК:

ping ИМЯ_СЕРВЕРА
ping -4 ИМЯ_СЕРВЕРА
ping -6 ИМЯ_СЕРВЕРА
nbtstat -a ИМЯ_СЕРВЕРА

Смысл:

  • ping — общий системный резолв;
  • ping -4 — пробует только IPv4;
  • ping -6 — пробует только IPv6;
  • nbtstat -a — отдельно проверяет ветку NetBIOS.

Шаг 3. Очистить кэши

На обоих ПК:

ipconfig /flushdns
nbtstat -R

Потом снова выполнить:

ping ИМЯ_СЕРВЕРА
ping -4 ИМЯ_СЕРВЕРА
ping -6 ИМЯ_СЕРВЕРА
nbtstat -a ИМЯ_СЕРВЕРА
ipconfig /displaydns
nbtstat -c

Что важно:

  • если рабочий ПК продолжает находить имя, а нерабочий нет, значит дело уже не только в старом кэше;
  • если после очистки у нерабочего ПК в displaydns появляется отрицательная запись — это полезный признак.

Шаг 4. Снять трафик на обоих ПК

На обоих ПК:

netsh trace start capture=yes report=disabled tracefile=C:\name_resolve.etl maxsize=256

После запуска последовательно выполнить:

ping ИМЯ_СЕРВЕРА
ping -4 ИМЯ_СЕРВЕРА
ping -6 ИМЯ_СЕРВЕРА
nbtstat -a ИМЯ_СЕРВЕРА

И затем открыть веб-адрес по имени в браузере.

Остановить:

netsh trace stop

Шаг 5. Что искать в захвате

Если видишь:

  • UDP 5355
  • адрес 224.0.0.252
  • или IPv6 multicast ff02::1:3

это LLMNR.

Если видишь:

  • UDP 5353
  • адрес 224.0.0.251
  • или IPv6 multicast ff02::fb
  • особенно если встречается .local

это mDNS.

Если видишь:

  • UDP 137
  • UDP 138
  • TCP 139

это NetBIOS.

Если видишь:

  • порт 53

это обычный DNS.

Шаг 6. Если есть Wireshark на клиентах

Фильтры:

udp.port == 5355
udp.port == 5353
udp.port == 137 || udp.port == 138 || tcp.port == 139
dns

Полезно и так:

ip.addr == 224.0.0.252 || ipv6.addr == ff02::1:3
ip.addr == 224.0.0.251 || ipv6.addr == ff02::fb

Что сравнивать между рабочим и нерабочим ПК:

  • есть ли сам запрос;
  • приходит ли ответ;
  • если приходит, то от какого IP;
  • не уходит ли один ПК в IPv6, а другой только в IPv4;
  • одинаковый ли механизм используется вообще.

Шаг 7. Зеркалирование на коммутаторе

Делать после клиентских захватов, когда уже понятно, что искать.

Зеркалировать лучше:

  • сначала порт сервера;
  • если нужно — транк в сторону сервера.

На зеркале в Wireshark смотреть:

  • приходит ли запрос от рабочего клиента;
  • приходит ли запрос от нерабочего клиента;
  • уходит ли ответ от сервера/ответчика;
  • одинаково ли это по IPv4 и IPv6.

Если сервер отвечает не сам, а имя резолвится через другой ПК/службу в VLAN, тогда SPAN только порта сервера может быть недостаточен. В таком случае лучше зеркалить транк VLAN или порт того узла, который реально отвечает на локальные запросы.

Шаг 8. Проверка коммутаторов

По VLAN, где сидят оба ПК и сервер:

show vlan id <VLAN>
show interfaces trunk
show spanning-tree vlan <VLAN>
show mac address-table address <MAC_рабочего_ПК>
show mac address-table address <MAC_нерабочего_ПК>
show mac address-table address <MAC_сервера>
show interfaces counters errors
show running-config interface <порт>

Отдельно проверить:

  • storm-control
  • port-security
  • ACL / VACL
  • private VLAN / изоляцию порта
  • ошибки на транках
  • multicast-настройки, если есть:
    • IGMP snooping
    • MLD snooping

Шаг 9. Проверка защиты на ПК и сервере

На клиентах и сервере, если доступ есть:

  • Windows Firewall
  • Kaspersky Firewall / Network Threat Protection

Что смотреть:

  • нет ли блокировки UDP 5355
  • нет ли блокировки UDP 5353
  • нет ли блокировки 137/138/139
  • нет ли временной блокировки IP второго узла
  • нет ли записей в журнале защиты на время проблемы

Как читать результат

Вариант 1

На нерабочем ПК нет запроса вообще
→ проблема локальная на клиенте.

Вариант 2

Запрос есть, но ответа нет
→ либо сеть, либо сервер/ответчик, либо защита режет ответ.

Вариант 3

Ответ есть, но клиент его не использует
→ проблема локального стека Windows, выбора IPv4/IPv6, кэша или защиты.

Что я бы сделал первым прямо сейчас

  1. Снять одинаковые выводы команд с обоих ПК.
  2. Очистить кэши и повторить ping / ping -4 / ping -6 / nbtstat -a.
  3. Снять netsh trace одновременно на обоих.
  4. По захвату понять, это LLMNR, mDNS, NetBIOS или вообще ничего.
  5. Только потом делать SPAN на серверный сегмент.
Back to top