Иногда бывает. Внедряешь новый Hyper-V кластер, всё идёт прекрасно. Пока... Пока не сталкиваешься с проблемой - коллега говорит: - "А что-то у меня в новом вилане по DHCP адреса не получаются. При этом статика работает прекрасно".
Запускаю старые машины в старом кластере в этом вилане - всё работает. Перетаскиваю старые машины в новый кластер - всё работает. Создаю новую машину - ничего не работает. При этом, сетевой стек наглухо виснет, помогает только перезагрузка машина.
Изучаю сеть, ничего найти не могу.
Создаю новую машину не на Windows Server 2019 (Windows 10), а на Windows 8.1 - всё работает.
Беру полноценный комп с Windows 10, тыкаюсь в этот же вилан - сетевой стек виснет. В других виланах всё прекрасно работает. А-ха, проблема где-то в Win10.
Сравниваю настройки DHCP в разных виланах: на первый взгляд - всё одинаково.
Собираю тестовый стенд, всё замечательно работает. Начинаю снимать дампы.
На первый взгляд, дампы одинаковы. С горя сношу настройки проблемного вилана в DHCP - и, о чудо, всё заработало!
Полез опять сравнивать дампы - и вот она, рыба моей мечты...
Когда-то давно мы с
__mixa__ запускали на сети опцию 119 (Domain search list). Эта опция отличается довольно кривой реализацией в продуктах от MS - Windows 7 её не поддерживает от слова совсем. Забить её правильно в консоли DCHP-сервера надо ещё постараться. Но нам она была нужна для никсовых серверов, где она прекрасно выполняла свою роль (в винде мы политиками обошлись).
Оказывается, что в Win10 (и производных - Windows Server 2019 и т.п.) таки реализовали поддержку (или не поддержку, а обработку) и на кривой опции 119 тупо крэшится сетевой стек. А кривость заключалась в ошибочном указании (!) одного байта при переносе опции с одного вилана в другой. В общем, Wireshark + WinHex = наше всё!
P.S. Включение Microsoft DHCP-сервера (отключение авторизации):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
Name: DisableRogueDetection
Type: REG_DWORD
Data: 0x1