у меня есть Windows Server 2012 R2 box, действующий как контроллер домена, который находится в изолированной локальной сети. Он также действует как DNS-сервер для этой локальной сети.
У меня также есть Sonicwall NSA 2600 брандмауэр, который установлен в качестве шлюза по умолчанию для всех машин в локальной сети, включая контроллер домена.
У нас есть отверстие в приложении для обновления Windows, которое проходит через брандмауэр, который отлично работает для других компьютеров в локальной сети.
Тем не менее, DC, похоже, играет, и код ошибки Центра обновления Windows
80072EE2
Кажется, что есть проблемы с подключением и к другим внешним сайтам, поэтому я пытался диагностировать проблему с сетью.
Я запустил pcap для этого, и происходит следующее:
DC -> firewall: DNS-запрос для [домен обновлений Windows]
брандмауэр -> DC: ответ DNS для [домен обновлений Windows] в xxx.xxx.xxx.xxx
DC -> трансляция: ARP, у которого есть xxx.xxx.xxx.xxx
Очевидно, он не получает ответа, поскольку IP-адрес внешнего обновления Windows не является частью локальной сети.
Когда то же самое на машинах с работающими обновлениями Windows, это выглядит так, как ожидалось:
хост -> брандмауэр: запрос DNS для [домен обновлений Windows]
брандмауэр -> хост: ответ DNS для [домен обновлений Windows] в xxx.xxx.xxx.xxx
хост: TCP SYN для xxx.xxx.xxx.xxx
Я проверил DNS брандмауэра, и он установлен на 1.1.1.1
DC iptables показывает каждый локальный / шлейф до 0.0.0.0. Исключение составляют маршруты 0.0.0.0/0, которые имеют две записи: 0.0.0.0 и [IP-адрес брандмауэра]
Файл hosts на DC также по умолчанию: 127.0.0.1 - localhost :: 1 - localhost
Конфигурация ipv4 статична и выглядит следующим образом:
IPv4-адрес: [IP-адрес постоянного тока]
Маска подсети: 255.255.0.0
Шлюз: [IP брандмауэра]
DNS: [IP-адрес постоянного тока]
Я действительно в растерянности - по всем учетным записям, сетевая сторона вещей должна работать, и вы ожидаете, что контроллер домена отправит TCP SYN на IP-адрес, указанный в ответе DNS.
Однако он просто даже не пытается этого сделать, а прыгает прямо в ARP.
У кого-нибудь есть идеи о том, что может быть причиной этого и что можно сделать, чтобы это исправить?
Дайте мне знать, если вы хотите получить дополнительную информацию.
Это не окончательный ответ, но он, похоже, кое-что исправил.
Поэтому мне следовало добавить, что основным активным интерфейсом был виртуальный интерфейс Hyper-V.
Это не подтверждено, однако проблема, по-видимому, должна быть решена (на данный момент), и я подозреваю, что это произошло из-за функции прокси-сервера ARP Hyper-V.
Также выяснилось, что драйвер устройства для физической сетевой карты работал некорректно (не позволял мне включить ipv4, даже если другие интерфейсы были отключены), поэтому я переустановил и включил его как основной интерфейс LAN.
Чтобы сохранить конфигурации Hyper-V, для которых может потребоваться интерфейс Hyper-V, я создал для них сетевой мост.