Используя Azure IaaS (через ARM), у меня есть конфигурация, в которой есть несколько шлюзов RDP без аутентификации домена. Эти устройства используются в качестве ступеньки для входа в виртуальную сеть, которая затем позволяет подключаться ко всем зарегистрированным в домене устройствам в виртуальной сети.
У меня нет репутации, поэтому я не могу вставлять изображения в строку. Найдите диаграмму Вот
В общем, это работает так, как задумано, позволяя RDP доступ ко всем устройствам в домене (показанным как подсеть 10.1.10.0/24 и 10.1.11.0/24), за исключением контроллеров домена, которые не могут быть надежно зарегистрированы таким образом. .
Наиболее частым признаком является сбой подключения, но иногда сеанс RDP запускается правильно, а затем происходит сбой (через пару секунд).
Если я установил постоянный пинг к контроллеру домена с (например) устройства в подсети 10.1.10.0/24, на эти пинги будут отвечать до момента сбоя соединения RDP, после чего они будут сброшены. В тот момент, когда возвращается сообщение об ошибке RDP или соединение RDP разрывается, на эхо-запрос снова отправляется ответ.
Если я настроил постоянный эхо-запрос от контроллера домена к (например) устройству в подсети 10.1.10.0/24, на эти эхо-запросы всегда отвечают, даже если эхо-запросы в другом направлении не работают.
Если я обнаружу контроллеры домена с публично маршрутизируемым IP-адресом и разрешаю этот входящий трафик через группу безопасности сети контроллеров домена, я могу надежно подключиться (используя те же учетные данные, что и выше) с общедоступного IP-адреса, но этот вектор - именно то, что я пытаясь избежать с этой конфигурацией.
Если я установил постоянный пинг для общедоступного маршрутизируемого IP-адреса, он всегда будет успешным, даже в сценарии, когда внутренний пинг (первый маркер выше) не работает.
Если я создам другой виртуальный сервер по умолчанию (не присоединенный к домену) в подсети контроллера домена, у него не будет такой проблемы. Если я присоединяюсь к новому серверу к домену, у него все равно не будет проблем. Кажется очевидным, что это как-то связано с тем, чтобы быть DC.
Записи DNS для всех устройств Azure указывают на контроллеры домена, а все остальное якобы в порядке, хотя на контроллерах домена не включены другие службы.
Все серверы Windows2016.
Что мне не хватает? Что заставляет контроллер домена терять входящее соединение, когда он имеет постоянное соединение изнутри виртуальной сети, но не извне?
Похоже, что ответ на это кроется в моей неспособности следовать инструкциям.
Состояние Microsoft что статические IP-адреса виртуальных машин контроллера домена должны быть настроены в конфигурации Azure NIC. Менее очевидна важность того, чтобы вы вообще не настраивали статические адреса в гостевой ОС. Petri.com сильнее в своих формулировках:
«Никогда не следует настраивать IP-конфигурацию виртуальной машины Azure в гостевой ОС. Новый контроллер домена будет жаловаться на конфигурацию DHCP - пусть он будет жаловаться, потому что это не причинит вреда, если вы будете следовать правильным процедурам».
Вышеупомянутые симптомы могут показаться ожидаемым, если вы не последуете этому совету.
