Устранение сбоев RDP для виртуальных машин EC2 (часть 1)

На прошлой неделе я столкнулся с неприятной проблемой с виртуальной машиной. Проблема заключалась в сбое RDP. Хотя поначалу эта проблема может не казаться катастрофической, вскоре она превратилась в одну из тех ситуаций типа курицы и яйца, которых боится каждый ИТ-специалист. Моя проблема заключалась в том, что мне не удалось установить подключение удаленного рабочего стола к моей виртуальной машине. Однако, к сожалению, мне не удалось решить проблему (по крайней мере, традиционными средствами), потому что я не мог подключиться к виртуальной машине.

Излишне говорить, что это была неприятная ситуация. Тем не менее, не все было потеряно. Если вы когда-либо сталкивались с ситуацией, когда удаленный рабочий стол не может подключиться к вашей виртуальной машине, вы можете предпринять некоторые действия, чтобы решить эту проблему.

К сожалению, не существует универсального волшебного средства от сбоя соединения RDP. Решение проблемы в конечном счете будет зависеть от условия, которое вызвало проблему в первую очередь. В таком случае я буду обсуждать несколько различных вопросов.

Удаленный доступ отключен

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

Если вы не можете установить RDP-подключение к виртуальной машине, потому что удаленный доступ для этой виртуальной машины отключен, то самый простой способ вернуться — настроить групповую политику на разрешение удаленного доступа. Параметр групповой политики, который включает или отключает подключение RDP, можно найти в редакторе объектов групповой политики по адресу: Конфигурация компьютера | Административные шаблоны | Компоненты Windows | Службы удаленных рабочих столов | Узел сеансов удаленного рабочего стола | Связь. Необходимо установить для параметра Разрешить пользователям удаленное подключение с помощью служб удаленных рабочих столов значение Включено.

Брандмауэр Windows блокирует трафик RDP

Еще одна распространенная причина сбоев подключения RDP заключается в том, что брандмауэр Windows блокирует трафик удаленного рабочего стола. Опять же, это может произойти, если кто-то решит закрыть порт брандмауэра, связанный с RDP, в целях повышения безопасности.

Как и служба удаленного доступа, брандмауэром Windows можно управлять с помощью параметров групповой политики. Параметры групповой политики, связанные с брандмауэром Windows, находятся в редакторе объектов групповой политики в разделе Конфигурация компьютера | Административные шаблоны | сеть | Сетевые подключения | Брандмауэр Windows | Профиль домена.

Хотя иногда можно решить проблему с брандмауэром Windows с помощью параметров групповой политики, в некоторых ситуациях может потребоваться немного больше творчества. Однако я бы порекомендовал сначала попробовать подход групповой политики, потому что он самый простой.

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

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

Если вы случайно используете одну и ту же версию Windows на обеих виртуальных машинах, то можно исправить конфликт подписи диска, но этот процесс довольно утомителен. Кроме того, зачем придумывать еще одну проблему, прежде чем решить исходную проблему? Мой совет: если ваша неисправная виртуальная машина работает под управлением Windows Server 2012 или 2012 R2, создайте временную виртуальную машину под управлением Windows Server 2008. Точно так же, если ваша неисправная виртуальная машина работает под управлением Windows Server 2008, создайте временную виртуальную машину, которая работает под управлением Windows Server 2012 R2. На самом деле не имеет значения, какая версия Windows работает на вашей временной виртуальной машине, если она новее Windows Server 2003 и не соответствует версии Windows, работающей на виртуальной машине, которую вы пытаетесь исправить. Кстати, если вы случайно используете одну и ту же версию Windows на обеих виртуальных машинах, вы можете найти инструкции по устранению коллизии подписи диска здесь.

После создания новой виртуальной машины вам потребуется подключить корневой том неисправной виртуальной машины к новой виртуальной машине в качестве вторичного диска. После этого войдите на временную виртуальную машину и откройте консоль управления дисками, введя команду diskmgmt.msc в командной строке сервера.

Когда откроется консоль управления дисками, вы должны увидеть виртуальный жесткий диск неисправной виртуальной машины, но этот диск может быть указан как отключенный. Если это произойдет, щелкните правой кнопкой мыши диск и выберите команду Online из контекстного меню.

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

Введите команду Regedit в командной строке сервера. Когда откроется редактор реестра, выберите куст HKEY_LOCAL_MACHINE. Теперь выберите команду «Загрузить куст» в меню «Файл» редактора реестра. Вам нужно будет загрузить нужный куст с диска неисправного компьютера. Выберите соответствующий диск и перейдите в папку WindowsSystem32configSYSTEM. Вам будет предложено указать имя ключа, но вы можете ввести любое другое имя. Имя не имеет значения.

Теперь перейдите в редакторе реестра к HKEY_LOCAL_MACHINESYSTEMControlSet001servicesSharedAccessParametersFirewallPolicy. Теперь ищите ключи с именами, похожими на xxxxProfile. Это включает в себя DomainProfile, PublicProfile и, возможно, другие профили. Выберите эти профили один за другим, а затем измените значение EnableFirewall с 1 на 0. Это отключит брандмауэр для виртуальной машины. Позже вы можете войти в виртуальную машину и настроить брандмауэр для поддержки RDP.

Чтобы завершить процедуру, закройте редактор реестра и снова откройте консоль управления дисками. Щелкните правой кнопкой мыши диск неисправной виртуальной машины и выберите команду Offline из контекстного меню. Это отключит виртуальный жесткий диск. Теперь выключите временную виртуальную машину и отсоедините диск от неисправной виртуальной машины. Теперь вы можете восстановить корневой том на виртуальную машину, откуда он был получен (он должен быть подключен как /dev/sda1). Идите вперед, загрузите виртуальную машину и проверьте свою способность устанавливать соединение RDP. Если вы можете установить RDP-подключение, вы можете избавиться от своей временной виртуальной машины.

Вывод

Как видите, есть способы исправить проблемы с RDP-подключением для виртуальных машин, работающих в облаке Amazon. Во второй части я завершу эту серию, показав вам еще несколько вещей, которые вы можете сделать, чтобы решить проблемы с RDP-подключением.