Я надеюсь, что кто-нибудь сможет мне помочь с этим.
У меня есть виртуальная машина Windows Server 2016, работающая на Hyper-v, хост также является Windows Server 2016. В случайное время подключение к сетевым ресурсам на других серверах через имя \\ СЕРВЕР не удастся, соединение с \\ IPADDRESS всегда работает.
Сервер подключен к виртуальному коммутатору с выделенным доступом к узлам адаптера Broadcom NetXtreme Gigabit.
Это единственный сервер на этом сайте, который подключен к нашему основному сайту через IPSEC VPN.
Сервер функционирует как контроллер домена, DHCP-сервер, DNS-сервер и файловый сервер.
Я впервые заметил проблему, когда репликация AD давала сбой. Дальнейшее расследование показало, что я не могу подключиться к контроллеру домена на нашем основном сайте через SMB \\ SERVER, но я мог подключиться с \\ IP. Проверка связи с сервером по имени работает, и DNS вроде бы работает.
При подключении к \\ СЕРВЕР возвращаются следующие ошибки: «Windows не может найти СЕРВЕР. Проверьте орфографию и повторите попытку» или «Сетевой путь не найден».
Я смог подключиться к другим серверам по имени на нашем основном сайте.
Когда я устранял неполадки, несколько часов спустя DFSR начал давать сбой на другом сервере на нашем основном сайте. Ошибка в журнале «Удаленный вызов процедуры завершился неудачно и не выполнен». При подключении к этому серверу я обнаружил те же симптомы, что и первый, с той лишь разницей, что проблемы со связью возникли позже.
Я перезагрузил виртуальную машину и обнаружил, что все вернулось к норме и работает, AD хорошо реплицируется, а DFRS подключен и работает.
На следующий день я зашел на сервер и обнаружил, что все снова не удалось и те же проблемы с сетью.
Дальнейшее устранение неполадок показало, что отключение и повторное включение сетевого адаптера Microsoft hyper-v восстанавливает подключение, но проблема возвращается в случайное время.
Журналы на сервере ничего необычного не показывают. За исключением ошибок репликации AD, DFRS и DNS. Ошибки DNS:
DNS-сервер обнаружил критическую ошибку в Active Directory. Убедитесь, что Active Directory работает правильно.
DNS-серверу не удалось привязать сокет протокола дейтаграмм пользователя (UDP) к 172.18.0.10. Данные события представляют собой код ошибки. Перезагрузите DNS-сервер или перезагрузите компьютер.
DNS-серверу не удалось открыть сокет для адреса 172.18.0.10.
Убедитесь, что это действительный IP-адрес для серверного компьютера. Если он НЕ допустим, используйте диалоговое окно «Интерфейсы» в разделе «Свойства сервера» в диспетчере DNS, чтобы удалить его из списка IP-интерфейсов. Затем остановите и перезапустите DNS-сервер. (Если это был единственный IP-интерфейс на этом компьютере и DNS-сервер мог не запуститься в результате этой ошибки. В этом случае удалите значение DNS \ Parameters \ ListenAddress в разделе реестра служб и перезапустите.)
DNS-серверу не удалось привязать сокет протокола управления передачей (TCP) к адресу 172.18.0.10. Данные события представляют собой код ошибки. IP-адрес 0.0.0.0 может указывать на допустимую конфигурацию «любой адрес», в которой все настроенные IP-адреса на компьютере доступны для использования. Перезагрузите DNS-сервер или перезагрузите компьютер.
Все ошибки в журналах исчезают после перезапуска сетевого адаптера Hyper-V. Я предполагаю, что эти ошибки вызваны проблемами с подключением.
Я где-то читал, что VMQ должен быть отключен на NIC хоста, что я проверил, и это было. Я также попытался удалить и переустановить сетевой адаптер Microsoft Hyper-V, а на хосте переустановить драйверы сетевой карты.
Кто-нибудь знает, что происходит, похоже, проблема с DNS, но DNS правильно разрешает имена с помощью nslookup.
Любая помощь будет принята с благодарностью.
Оказывается, я искал не в том месте. Проблема была в VPN между сайтами.
После запуска захвата пакетов я мог видеть, что некоторые пакеты не доходили до места назначения, и повторялись повторные передачи. Дальнейшее расследование показало, что для пакетов, не попавших в этот список, установлен бит DF.
Использование ping -f -l SIZE SERVER
Мне удалось определить значение MTU 1362, и я заметил, что пакеты, не проходящие с установленным битом DF, были больше этого. Поскольку они не могли быть фрагментированы, они отбрасывались маршрутизатором.
Снижение максимального MSS с 1400 до 1350 на нашем устройстве безопасности на основном сайте решило проблему.
Полагаю, однажды я заметил, что перезапуск сетевого адаптера решит проблему на некоторое время, и предположил, что проблема связана с сервером.
В любом случае рад, что он отсортирован, не уверен, что этот пост кому-то поможет, но, по крайней мере, на него есть ответ.