Запросы службы имен NetBIOS не отправляются или не отвечают
У меня есть серьезное несоответствие в моих системах того, работают ли запросы службы имен NetBIOS на конечных точках. Я тестирую с системами Win7 и Server 2008R2. У нас нет сервера WINS и мы не хотим его иметь, но меня больше всего интересует другое поведение. Драйвером здесь является наш сканер Nessus, который получает имя системы, запрашивая у устройства его NetBIOS-имя, используя плагин 10150, который, очевидно, делает то же самое, что и nbtscan,
Как я понимаю и наблюдаю это, Несс, nbtscan и работает nbtstat -A XX.XX.XX.XX отправьте пакет netbios-ns на UDP-порт 137 на получателе, который должен ответить UDP-портом 137 на ответ запрашивающей стороне. Когда я наблюдаю это с помощью Wireshark на проблемной машине, я вижу, что пакеты приходят, но ответ не отправляется. Но некоторые системы отвечают, как и ожидалось. Я думаю, что здесь я исключил брандмауэр хоста, поэтому давайте предположим, что пока.
Кроме того - и это, возможно, странная вещь - в этих системах, которые не отвечают, они также, кажется, не пытаются отправлять пакеты UDP, когда я выдаю nbtstat -A XX.XX.XX.XX команды. Они немедленно выходят с сообщением "Хост не найден", и Wireshark не показывает исходящих пакетов (рабочие системы генерируют до трех пакетов, прежде чем отказаться).
Это как если бы подсистема NetBIOS-NS была отключена в этих системах, и она не пытается использовать ее, но я не могу найти доказательства установки, которая могла бы вызвать это. Еще больше расстраивает то, что ни одна из документов Microsoft, похоже, даже не признает существование этого метода разрешения одноадресных имен - все, что вы читаете, говорит только о широковещании или обмене сообщениями на сервере WINS. Кстати, как работающие, так и нерабочие системы находятся в гибридном режиме по ipconfig /all и я явно настроил интерфейсы для включения NetBIOS через TCP/IP, что не помогло. Я вижу через netstat -an что ядро прослушивает UDP-порт 137, но эти сообщения остаются без ответа.
Где-то есть настройка, которая вызывает поведение, которое я вижу? Это кажется наиболее вероятным ответом, но мой поиск ничего не дал.
Обновить
Теперь я также наблюдаю, что пакеты UDP передаются, если запрос направлен на другой IP в той же подсети. Итак, это материал. Но, опять же, я не знаю, почему поведение некоторых хостов отличается. Почему некоторые из моих систем отправляют (и отвечают на) пакеты UDP для NetBIOS-NS только для IP-адресов в локальной подсети?
1 ответ
У меня возникла проблема: несколько компьютеров не могли получить доступ к общему ресурсу SMB на старой машине под управлением Windows 95 (да, я знаю...), подключенной к отдельной сети VLAN без подключения к Интернету. Немногие компьютеры смогли подключить общие ресурсы, но постепенно со временем просто перестали работать.
Я покопался с помощью Wireshark и увидел, что последний работающий компьютер отправляет запросы NBNS, чего не делают нерабочие компьютеры. Точно так же, как в этом случае, nbstat -A сразу же вернул «хост не найден». Перемещение компьютеров в одну и ту же VLAN снова заработало, но на самом деле это не было решением, поскольку подключение к Интернету является обязательным на компьютере, который подключается к старому ПК.
После нескольких месяцев периодических исследований я наконец понял это:
https://support.microsoft.com/en-us/kb/3161949
Связь NETBIOS за пределами локальной подсети усилена. Поэтому по умолчанию некоторые функции, зависящие от NETBIOS (например, SMB через NETBIOS), не будут работать за пределами локальной подсети. Чтобы изменить это новое поведение по умолчанию, создайте следующую запись реестра:
ПОДКЛЮЧ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters Имя значения: AllowNBToInternet Тип: Dword Значение: 1 Значение флага по умолчанию: 0
После добавления ключа в реестр и перезагрузки nbtstat -A xx.xx.xx.xx начал отправлять запросы, и общий ресурс SMB снова заработал. Надеюсь, это поможет, если кто-то наткнется на это в будущем.