Wins server для linux

СЕРВЕР WINS ДЛЯ ДОМАШНЕЙ СЕТИ

ВНИМАНИЕ! Услуга сервера WINS временно не предоставляется с 1-го августа 2019 года

Услуга WINS сервера (Windows Internet Name Server)

Включая эту услугу в сети VPNKI, вы получаете возможность использовать протоколы сети Microsoft Windows внутри своих VPN туннелей. Это позволит вам обращаться к устройствам внутри своей сети по их именам, например, такого вида \\SERVER или \\COMPUTER

Также вы сможете использовать функцию browse (просмотр) ресурсов Microsoft Windows в своей сети. За это обычно отвечает вкладка «Сеть» или «Сетевое окружение» в различных версиях Windows. Используя WINS вы сможете видеть, например, такую картинку.

на этой картинке:

— CAR это домашний ноутбук,

— WINS — это сервер имен VPNKI,

— VILLAGE и FOREST — устройства RaspberryPi на даче,

— KUT — тоже RaspberryPi, но в городской квартире,

— LIL — сервер в квартире родителей

Как видно из картинки основная задача сервера WINS это нахождение компьютера по его имени в сети Microsoft. Это почти как DNS служба в Интернете, только для протокола Netbios. Признаться честно, нелогичность работы этой службы и количество различных терминов, рожденных внутри компании Microsoft для ее работы это тема отдельной статьи.

В этой инструкции мы постараемся кратко отразить работающие настройки и при этом не сильно углубляться в происходящее. Работа Netbios и WINS внутри локальной сети далеко не оптимальна, а уж внутри VPN это двойной кошмар 🙂

Пример использования

Допустим, что в вашей домашней сети есть сервер или компьютер с именем \\SERVER, на котором в общее пользование (в терминах Microsoft Windows) дана сетевая папка PHOTOS. Вы хотите обращаться к этой папке из любого места своей сети, даже в случае подключения через VPN.

1. Для этого вам необходимо активировать услугу WINS сервера, который выступит единой точкой регистрации ресурсов Microsoft Windows внутри вашей распределенной сети. Его адрес в вашей сети — 172.16.255.10

ВАЖНО 1: Одно маленькое условие — все это будет работать в том случае, если ваш компьютер или сервер принадлежат к так называемой рабочей группе с именем WORKGROUP

Проверить это можно в ОС Windows, зайдя в параметры системы:

Если у вас в параметрах системы стоит WORKGROUP, то смело двигайтесь дальше. Если нет — то можете поменять. Правда придется перезагрузиться.

После запуска сервера проверьте его доступность, выполнив команду ping 172.16.255.10 (естественно при подключенном туннеле к системе VPNKI).

2. Если пинг был успешен, далее осуществите регистрацию своих устройств, обладающих ресурсами Microsoft Windows (расшаренные папки, принтеры и другие устройства). Регистрация подразумевает прописывание адреса сервера WINS сервера — 172.16.255.10 в настройках своих устройств. Для этого необходимо внести некоторые изменения:

2.1. Для устройств с ОС Windows в настройках сетевого подключения (VPN туннеля к VPNKI) настройте галочки так, как показано на картинках ниже и укажите адрес сервера WINS

2.2. Для устройств с ОС Linux укажите адрес WINS сервера 172.16.255.10 в настройках файла /etc/samba/smb.conf

Если у вас нет samba, то поставьте ее командой sudo apt-get install samba

Не забудьте проверить имя рабочей группы, она должна быть — WORKGROUP

Ставить «wins supprоt = yes» ни в коем случае не стоит, так как это заставит вашу самбу быть wins сервером.

После этого перезапустите samba (service samba stop, service samba start для систем с systemd или /etc/init.d/)

3. После внесения изменений в настройки сетевого соединения (для ОС Windows) или в настройки Samba (для Linux) установите соединение с VPNKI и подождите около 10 минут.

В течение этого времени происходит умопомрачительный процесс регистрации ресурсов в WINS сервере (по-другому и не скажешь про протокол Netbios).

После этого вы можете попытаться обратиться к своему ресурсу, набрав в строке проводника Windows его имя в формате \\ИМЯ.

Я таким образом обращаюсь ко всем своим серверам на первой картинке. например \\LIL или \\FOREST

4. Конечной точкой всего мероприятия было желание увидеть все свои ресурсы в сетевом окружении (на компьютере с ОС Windows). Попробуйте — при правильной настройке они должны там появиться. Как минимум, сам сервер WINS вы должны увидеть. Однако есть и сложность .

ВАЖНО 2: Функция Browse (то есть поиск ресурсов в сети) будет работать в том случае, если в вашей сети НЕТ какого-либо устройства, которое исполняет роль Local Master (или Master Browser). Бывает так, что при запуске службы smb на домашних маршрутизаторах именно ваш маршрутизатор становится Local Master в вашей сети и этой своей функцией он будет мешать обзору и поиску ресурсов Netbios во всей вашей сети.

5. После успешной регистрации ресурсов на WINS сервере вы сможете обращаться к ним из любой точки своей сети, даже при подключении через VPN туннель.

Устройство, которое будет подключаться через VPN туннель также должно использовать настройку WINS сервера, которую можно:

• жестко указать в настройках VPN подключения, как было указано в п.2.1. (адрес WINS сервера виден на вашей странице — 172.16.255.10)
• или получить адрес сервера WINS по протоколу DHCP при подключении туннеля к VPNKI (только для устройств, поддерживающих DHCP)

Если вы хотите получать адрес сервера WINS автоматически, то укажите эту необходимость на странице «Применить приложения к туннелям», установив галочку напротив выбранного туннеля.

Технические особенности

Ваш WINS сервер по адресу 172.16.255.10 является только сервером имен рабочей группы WORKGROUP и не содержит никаких иных данных.

Если вы устанавливаете VPN соединение с ПК, который подключен к офисной сети, которая также имеет имя рабочей группы WORKGROUP, то в своем сетевом окружении вы, скорее всего, увидите не только рабочие станции своих офисных коллег, но и свои домашние ресурсы. Не переживайте — никто кроме вас не видит эти имена, просто ваш Windows объединил их отображение на единой странице.

Период тестирования услуги

Мы планируем что период тестирования услуги WINS сервера займет около месяца.

Отказ от услуги

Вы можете в любой момент отказаться от услуги. В этом случае все регистрации ваших устройств будут удалены, а сервер WINS остановлен.

Источник

Настройка VPN с использованием wins сервера

У локальной сети ипшники 172.16.*.*. А у впн сервера 192.168.254.5.
В винде для подключения к впн серверу указан wins сервер 192.168.1.24.
Как мне тоже самое сделать под линухом?

Добавил в настройки самбы параметры:

Но впн сервер всеравно не пингуется. Что мне сделать, чтобы впн сервер стал доступен?

Ты видимо не понимаешь что такое WINS и что он делает. WINS — это что-о вроде упрощённого DNS для виндовых машин. У тебя в настройках указан WINS, чтобы компьютер смог зарегистрировать в нём своё имя. К VPN (в твоём случае это PPtP) это не имеет никакого отношения.

Но впн сервер всеравно не пингуется. Что мне сделать, чтобы впн сервер стал доступен?

• Какой у тебя установлен дистрибутив и какой он версии?
• Как давно ставил все обновления?
• Каким способом и как настроена сеть?
• Покажи вывод команды

Дистрибутив Fedora 14. Поставил из коробки, обновлений не ставил. Локальная сеть работает, согласно настроек из винды (кроме винс сервера, не знал куда его пехнуть) Вывод команд щас скопирую (надо перезагружаться)

Я правильно понимаю, что у тебя сеть настраивается статически (т.е. надо руками вбивать все настройки), а не по DHCP?

IP PPtP-сервера, — 192.168.254.5 — не входит в подсеть 255.255.252.0, поэтому пинги и не идут. Система просто не знает через какой интерфейс нужно отправлять пакеты на этот адрес. По идее тебе нужно добавить маршрут на подсеть 192.168.0.0/255.255.0.0. Если ты настраивал сеть через NetworkManager, то там для этого есть кнопочка «Маршруты. » на вкладке «Параметры IPv4». В командной строке маршрут можно добавить так:

Да, все настройки локальной сети статичные

Насчет маршрута — спасибо, сейчас попробую.

кроме винс сервера, не знал куда его пехнуть

Ты его правильно впихнул: в smb.conf. Только убери wins support, wins proxy и dns proxy, это настройки WINS-сервера, а у тебя samba должна работать в качестве WINS-клиента с посторонним WINS-сервером. И эта настройка имеет смысл только если ты хочешь держать samba-сервер с файлосвалкой, на которую другие пользователи внешней сети (провайдера?) должны заходить по имени, заданном параметром netbios name в smb.conf.

Почему то не помогло, в чем может быть причина?

спасибо

Блин пересмотрел еще раз настройки vpn под виндой, и в настройках указан не тот ип адрес, что в моем скрине. Поставил этот ип в скрипт коннекта и все заработало.

Источник

Wins server для linux

Windows* — MS Windows 95, 98, NT 3.5x/4.

Компьютер — как правило, компьютер с Win NT 4.0. Идеология относится и к W9x, но я рассматриваю NT.

Сеть — сегментированная сеть на основе TCP/IP.

Broadcast — специальный широковещательный пакет; broadcast обязаны обработать все компьютеры, которые его получат.

jfyi: NetBEUI — NetBIOS Extended User Interface — родной для Windows* протокол. Замечателен тем, что a) [1] не умеет маршрутизироваться, поскольку в нем нет networking layer и b) использует только broadcasts для распознавания имен и сервисов, по каковым причинам в чуть более серьезных местах, чем сетка на 5-10 компьютеров нормальными людьми не используется.
Не путать с NetBIOS, схожесть этих имен уже породила массу терминологических противоречий.

SAMBA — комплекс программ для доступа к файл- и принт-сервисам Windows*, в тексте идет речь о samba версии

1. NetBIOS — Network Basic Input Output System [2]

1.1. NetBIOS — это session-level интерфейс. Используется программами для общения over NetBIOS совместимых транспортных протоколов. Транспортные протоколы — это NetBEUI, TCP/IP, IPX/SPX. Cеть Windows* не живет без NetBIOS. Никогда. Ни при каких условиях. Даже под угрозой расстрела. Неважно, что там у вас написано в свойствах сетевого окружения — если есть это самое окружение, значит есть и NetBIOS. Он отвечает за логические имена компьютеров на сети и передачу данных между двумя компьютерами, установившими между собой сессию.

NetBIOS over TCP/IP называется NetBT.

1.2. NetBIOS names

NetBIOS name закрепляется за ресурсом — не за компьютером! — только за ресурсом, имеет размер в 16 байт. Первые 15 — собственно имя, 16-й — тип ресурса, (00-FF hex), типы стандартизованы.

Имена делятся на:

1. Unique (U)- к этому имени может быть привязан только один адрес.
2. Group (G) — к этому имени не привязан адрес; На запрос WINS клиента об адресе всегда возвращается limited broadcast address.
3. Multihomed (M) — не описан в rfc 1001/1002; к этому имени может быть привязано до 25 адресов; TTL общий для всех..
4. Internet Group (Special Group) (I) — к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL.
5. Domain Name (D) — про него сказано коротко: «New in Windows NT 4.0.»

NetBIOS suffixes

1.3. Name Resolution

Name Resolution в NetBIOS от рождения основано на broadcasts, что сильно осложняет жизнь уже в средних размеров сети — любой свитч [c2] broadcast’ы через себя не пропускает, и правильно делает [3] . Ранние версии NetBIOS’а умели пользваться для распознавания имен только

1. NetBIOS name cache
2. IP subnet broadcasts
3. LMHOSTS

К версии NT 3.5 MS одумался и ввел улучшения. Сейчас NetBIOS умеет пользоваться

1. NetBIOS name cache — посмотреть в своем собственном кэше — нет ли там искомого имени; в кэше имена обычно остаются на 10 мин.
2. NetBIOS name server — WINS, о котором речь пойдет дальше
3. IP subnet broadcasts — громко крикнуть на всю (под)сеть: «А подать сюда Ляпкина-Тяпкина!»
4. Static LMHOSTS file, для WINS клиента:

102.54.94.97 rhino #PRE #DOM:networking #net group’s DC
102.54.94.102 «RTS \0x1c» [4] #special app server
102.54.94.123 popular #PRE #source server
102.54.94.117 localsrv #PRE #needed for the include
#BEGIN_ALTERNATE
#INCLUDE \\localsrv\public\lmhosts
#INCLUDE \\rhino\public\lmhosts
#END_ALTERNATE
Директивы (#PRE, #DOM, etc) описаны внутри lmhosts.sam.

1.4. Что бы хоть как-то управлять этим разнотравьем, вводится понятие NodeType для порядка регистрации и распознавания имен [5] :

Использует только broadcasts.
В TCP/IP от MS используется «Microsoft Modified B-Node»:
1. кэш 2. Broadcast 3. LMHOSTS

Использует только WINS. Если WINS не работает, то ни регистрации, ни распознавания [c1] . M-node (Mixed) Для регистрации использует broadcasts. Для распознавания использует broadcasts, но если не получает ответа, то переключается в P-node. H-node (Hybrid) Пытается стать P-node; если WINS не работает, переключается в B-node. Переключается в P-node, как только находит WINS server.

NodeType раздаются DHCP сервером либо (surprise, surprise!) выставляются в registry

По умолчанию (при сконфигурированном WINS server’e ) Windows* встает в H-node.

2.1. WINS — Windows Internet Naming Service.
WINS server == NetBIOS Name Server (NBNS), но в MS по традиции (чтоб жизнь медом не казалась) используются оба термина. Для тех, кто знаком с DNS, достаточно сказать что WINS — это такой DNS от Microsoft — для NetBIOS’a. WINS отвечает за регистрацию Netbios’овских имен и преобразование их в IP адреса. WINS хранит базу данных вот такого вида:

Поля A и S — Active и Static, Version ID — уникальный номер, который используется MS WINS’ом при репликации — для поиска новых записей (репликация — процедура слияния баз нескольких WINS серверов).

WINS — в своей работе использует UDP -137 и 138 порт (и broadcast’ы — если поймает).

На сегодняшний день я знаю два WINS сервера — один из них поставляется с NT server, второй включен в пакет SAMBA. Какой из них использовать — дело вкуса; если хочется [псевдо]спокойной жизни, надо использовать сервер от MS. Упадет NT с WINS сервером — последствия для своего случая прикидывайте сами.

Если доверять продукции MS не хочется, то придется использовать samba, несмотря на ее недостатки. К недостаткам относятся два пункта:

1. Нет возможности реплицировать между собой два WINS сервера;
2. Честное следование rfc. SAMBA пишется наивными людьми, которые верят, что MS следует своим спецификациям. Понятно же, что там где-то что-то будет сделано хоть чуть-чуть, но не так. Если уж писать WINS сервер под MS, то с отладчиком, дизассемблером и tcpdump’ом в руках. Чтобы аккуратно повторять все ошибки MS (см. Readme к service pack’ам на предмет слова WINS).

2.2. Как работает WINS сервер

Основная задача WINS server’а — уметь отвечать на вопрос — а какой адрес у сервиса «name».

Функции Name Registration, Refresh, and Release: Сервис грузится, шлет на WINS сервер пакет Registration. В ответ получает подтверждение ( различные ошибки и конфликты опускаю ) и время, в течение которого его регистрация действительна — TTL. Согласно описанию от MS через TTL/2 NT [6] (остальные клиенты могут делать refresh с другой частотой, но до истечения TTL) должна прислать Refresh — мол вот она я, жива. И снова получить TTL. И так до окончания работы, когда сервис должен послать пакет Release. Если TTL истек, а сервис Refresh не прислал, WINS server о нем забывает.

MS WINS server умеет реплицировать свою базу с другими MS WINS серверами.

Итак, с помощью WINS сервера можно получить адрес ресурса по имени «name». Но как увидеть список всех компьютеров в сети/домене/рабочей_группе? WINS на такие вопросы не отвечает — не обучен. Занимаются этим всяческие browser’ы. В каждой подсети есть master browser( domain \0x1d), backup browser, potential browser и preferred master browser, их в последнее время называют segment browsers ( изобретенными в MS терминами можно, наверное, библиотеку заполнить ).

Компьютеры, таким образом, разделяются на:

1. Non-browser компьютеры
2. Potential browsers — может стать backup browser’ом, если понадобится.
3. Backup Browser — оперирует Browse lists’ами серверов и доменов, каковые lists получает от Master Browser.
4. Master Browser — Получает анонсы от компьютеров и доменов, посылает Browse list Backup Browsers’ам, высылает по запросы клиента Browse list, продвигает Potential в Backup Browser по мере необходимости и общается с Domain Master Browser.
5. Preferred Master Browser — то же самое, что и Backup, но выигравший выборы за счет установки в registry флажка IsDomainMasterBrowser [c3] в True.
6. Domain Master Browser — Согласно MS’овской документации функции domain master browser’a всегда выполняет primary domain controller [7] , и лучше бы этому не препятствовать, хотя samba и умеет (domain master = yes).

Неважно, что у вас в подсети/домене/рабочей_группе одна машина — она будет и master, и backup, и potential. На каждые 32 компьютера добавляется еще один backup browser. Master browser’ы занимаются тем, что обрабатывают broadcast’ы, которые раз в time=12 минут выдает каждый компьютер и складывают результаты в browsing lists глубоко внутри себя.

Если компьютер в течении time*3 признаков жизни не подает, master browser удаляет его из browsing list. Итого тайм-аут между выключением компютера и пропаданием его из neighborhood составляет 36 мин. — внутри одного сегмента. Если компьютер выключен «gracefully», browser (имеется в виду сервис computer browser) пошлет master browser’у соответствующее сообщение и будет вычищен из списков сразу.

В дополнение все master browser’ы периодически [8] анонсируют себя принадлежащими к группе \0x01\0x02__MSBROWSE__\0x02\0x01 [9] в локальной подсетке — без использования WINS, broadcast’ом. В анонсе присутствуют имя домена и имя domain master browser’a. Master Browser’ы, получающие такие анонсы, хранят их в internal browse lists [10] вместе с именем компьютера, пославшего анонс.

Backup browser кэширует browsing lists у себя и инициирует перевыборы , если не может найти master browser.

Domain master browser составляет список имен master browser’ов на основании полученных от них Master Announcement frames, которые ему присылают сначала после победы на выборах, а затем каждые 12 (у самбы — 15) минут. На основании этого списка domain master browser раз в 15 минут опрашивает всех master browsers на предмет local browsing lists, соединяет полученное в domain browse list и раздает (по запросу, который раз в 12 минут) master browser’ам. Сами считайте , через сколько минут выключенный компьютер пропадет из browsing lists в остальных сегментах.

Свежезагрузившийся клиент шлет broadcast [11] на имя domain \0x1d. Master browser возвращает соответствующий список browser’ов, из коего списка клиент выбирает три сервера и, случайным образом образом из этих троих выбрав одного, шлет запрос. Результат появляется в network neighborhood’e. При обращении к компьютеру, нарисованному в Network Neighborhood идет запрос к WINS серверу о его адресе.

В NT за browser’енье отвечает сервис Computer Browser.

Кусок документации от samba — объяснение на пальцах того, как синхронизируются Browsing lists в подсетях, взято из файла browsing.txt; переводить мне его лень.

Итого, в сегментированной сети с Windows*-клиентами без WINS’а Browsing lists не работают. А поскольку слова «сеть работает» проверяются наличием соседских компьютеров в Network Neighborhood, то .

Хотелось бы добавить пару слов о multihomed master browsers — у которых более одной сетевой карты.
Собственно, MS их категорически не рекомендует. Дело в том, что NT’шный browser отдает не полный browse list, а только ту его часть, которая относится к подсети откуда пришел запрос (возможно, в действительности значение имеет то, на какой адрес он пришел — негде сейчас проверить). MS объясняет, что, мол, browser знать ничего не знает о роутинге между подсетями, и поэтому отдавать чужую подсеть ему не с руки.
Кое-как это лечится при помощи Q158487 — оставляем компьютер browser’ом только в одном из сегментов. Если бедной кляче к тому же посчастливилось быть PDC, то придется прописать в WINS (или в lmhosts на potential browsers) static mapping типа multihomed для имени domain\0x1b с адресом интерфейса из этого сегмента — это чтобы master browser’ы всегда обращались по правильному адресу.
Самба всегда отдает объединенный browse list, поэтому делать ее master browser’ом бывает очень чисто и сухо.

Уф. Комментировать такой подход я не в силах, но вот коротенькое резюме:

Все, что касается browsing lists, происходит, как это водится у MS, «автомагически». Влиять на эту политику я умею только одним способом — поубивав [12] сервис computer browser на всех NT в подсетке, кроме одной, это оставит ее local/backup master browser’ом, навсегда. Но как только эта единственная NT упадет, пропадет содержимое neighborhood.

Так что и этот подход на практике использовать нельзя.

Материалы для внеклассного чтения от MS: winswp , tcpipimp2 , ntbrowse .

Предложения, пожелания, bugfixes(к тексту, не к MS) шлите мне.

Maxim Berlin, 31.01.2000.

Выношу благодарности за помощь в работе над этим материалом:
Александру Калагову (ТЦ РТС),
Игорю Нестерову (ТЦ РТС),
Владимиру Чухареву,
Vladimir Pastukhov,
Sergei V. Dubrov.

Возникшие вопросы:

1. Дмитрий Шеремет: Как задать адрес, на котором WINS сервер будет принимать пакеты?
   A : Для NT я не умею. Похоже, MS WINS server хватает первый попавшийся адрес (alias или сетевую карту). Samba поступает лучше — ей можно задать ( socket address = ) адрес сокета, который нужно слушать, но сама себя она анонсирует на первом попавшемся адресе. Например: на сетевой карте есть два алиаса xx.12 и xx.3, socket address = xx.12. Samba честно будет слушать xx.12 адрес, но в WINS ее адрес будет xx.3, со всеми вытекающими последствиями. Алгоритма выбора адресов я не знаю.
2. Владимир Чухарев: Кто будет исполнять функции Domain master browser’а, если на сети нет Primary/Backup domain controller’а?
   A1 : Не знаю. Кто знает, напишите мне, пожалуйста.
   A2 , Vladimir Pastukhov: Не хочет NT быть DMB без домена, однако. Даже если ее адрес насильно в WINS прописАть с именем workgroup[1b], самба все равно на попытки синхронизироваться получает в ответ RST.
   Резюме : Если нужен domain master browser и не нужен domain, необходимо ставить samba.

[1] За счет пункта a) NetBEUI остается самым быстрым и маленьким сетевым протоколом

[2] NetBIOS изначально находился в ROMе сетевых карт для писюковой сетки от IBM.

1. Не путай роутер и свитч. Далеко не всякий свитч режет броадкасты.
2. Обычным свитчом я называю железяку, работающую только на уровне MAC-адресов, т.е., также, как и старые добрые бриджи. Классические, первые свитчи — это просто многопортовые буферированные бриджи, они пересылают пакеты из-в сегмента в сегмент только на основании MAC-адреса фрейма (Ethernet, FDDI, и пр.). Они ничего не знают про .255 бродкаст (IP-level) — для них это такой же пакет, как и остальные. Если чуть вдаться в подробности, даже классический свитч, работающий на втором уровне, но имеющий достаточно мозгов внутри, может в принципе иметь возможность строить фильтры по различным полям принимаемых-передаваемых фреймов, т.е., его можно научить, например, зная структуру IP-пакета, упакованного в Ethernet-фрейм, откидывать бродкасты сетевого уровня. Из примеров таких железок — LanPlex2500 (сейчас — CorePlex2500) от 3Com.
Новые, современные и достаточно навороченные свитчи уже обычно могут работать с третьим уровнем — сетевым (те же VLAN-ы), вот на них уже действительно можно без приседаний в виде писания фильтров на птичьем языке машины а-ля Тьюринг работать с пакетами на уровне IP или IPX, например, в т.ч. устраивая no passaran для IP-бродкастов ;-). Хотя, с другой стороны, и сейчас выпускается масса дешевых свитчей фирмами типа D-Link, SMC и т.п., которые про сетевой уровень (и про VLAN-ы) ничего знать не знают.

Про канальный, сетевой и прочие уровни можно прочитать здесь: Протокол, интерфейс, стек протоколов. Модель ISO/OSI.

[3] Документация от MS всегда ставит проблему злобных роутеров на первое место. Роутеры, мол, не пропускают броадкасты. Вторым пунктом упоминают, что броадкаст должен быть обработан каждой машиной, имевшей счастье его словить, за что его роутеры и не пускают.

[4] Внимательно считаем пробелы между именем и типом. Тип должен быть 16-м.

[5] Я видел упоминание о «Microsoft-enhanced — Local LMHOSTS file or WINS proxies plus Windows Sockets gethostbyname() calls (using standard DNS and/or local HOSTS files) in addition to standard node types.», но живьем ее никогда не видел.

Мои эсперименты с node type на W95 (до OSR2) показывали, что p-type при отсутствии wins сваливается в b-type (по крайней мере начинает слать broadcast’s). В отличии от h-type — необратимо. По этой причине им пользоваться просто не стоит никогда. И, если склероз мне не изменяет, именно p-type стоит по умолчанию на указанных w95 (при сконфигуренном wins и запрете быть броузером). Это было лет пять назад.

c3 Vladimir Pastukhov: Ключ IsDomainMasterBrowser на самом деле называется IsDomainMaster — документированные грабли.

[7] В его registry есть некий(не уточняется) ключ, который помогает ему выиграть на выборах титул Domain Master Browser’а. «This allows browsing to be effective when a domain spans multiple subnets.» Не спрашивайте, чем оно будет эффективнее — не скажу. Не знаю.

[8] Написано — «periodically». Подозреваю, что либо раз в 12, либо раз в 15 минут.

[9] WINS server на запрос о таком имени всегда возвращает broadcast адрес соответствующей сети

[10] Понятия не имею, что это такое. Нашел только одно упоминание:»: In addition, master browser servers receive these domain announcements to this name and maintain them in their internal browse list along with the announcer’s computer name.»

[11] «A client will broadcast to this name to get a list of browser servers from the Master Browser.» Возможно, имелся в виду multicast.

[12] Или запретив в registry. Чревато. Установка Option pack для NT server с выключенным computer browser оканчивается (не начавшись) сообщением «Cannot detect OS type».

Источник