☰

Почему я не могу получить удаленный доступ к iDRAC9?

tag-icon • tag-icon router rdp redirection drac
Почему я не могу получить удаленный доступ к iDRAC9?

У меня Dell PowerEdge T350 с iDRAC9 Basic. Сервер подключен к коммутатору, который подключен к маршрутизатору выше по потоку, который подключен к Интернету. Очень просто. И NIC1 сервера подключены к коммутатору, и собственная карта UTP LAN iDRAC. Я включил iDRAC и могу получить доступ к веб-интерфейсу с другого хоста, подключенного к тому же коммутатору (он же интрасеть).

Оба интерфейса локальной сети сервера имеют статические IP-адреса интрасети (в диапазоне 192.168.1.x), а не DHCP-d, так как на маршрутизаторе есть трансляции портов, нам лучше иметь фиксированный IP-адрес. Я настроил трансляции портов на маршрутизаторе так, чтобы можно было удаленно получить доступ к двум службам: RDP и iDRAC. RDP — это сама ОС сервера.

А вот и самое интересное:

  1. Я могу получить доступ к серверной ОС с помощью RDP через интранет
  2. Я могу получить удаленный доступ к серверной ОС через RDP.
  3. Я могу получить доступ к веб-интерфейсу iDRAC через интранет
  4. Я НЕ МОГУ получить удаленный доступ к веб-интерфейсу iDRAC

Я настроил перенаправление порта iDRAC (или мы можем назвать это отверстием брандмауэра) так же, как и с RDP. Хотя для RDP требуется перенаправление как TCP, так и UDP 3389 портов. Для iDRAC требуется только перенаправление порта TCP 443.

Вопросы:

  1. Есть ли на iDRAC какой-либо переключатель или параметр конфигурации, который по умолчанию запрещает доступ к интрасети? (Хотя маршрутизатор выполняет преобразование адресов/NAT, так что этот вопрос может даже не иметь смысла?)
  2. Маршрутизатор, о котором идет речь, — это PACE 5268AC FXN. Я не могу найти в руководстве ничего, что указывало бы на то, что он допускает перенаправление 3389 (или также 3390, потому что я также заблокировал RDP другой машины), но не будет работать с HTTPS. Я не вижу ничего полезного в журнале брандмауэра, что могло бы помочь. Кажется, что каким-то образом входящие пакеты интрасети 443 даже не доходят до маршрутизатора? Я не понимаю.
  3. Я также пробовал 33443 -> 443 и другие типы перенаправлений вместо 443 -> 443, но это тоже не сработало.
  4. Я также добавлю, что SSL-сертификат iDRAC недействителен, но, похоже, что он дает сбой на каком-то более раннем этапе. Провайдер — AT&T.

Для справки: моя версия прошивки iDRAC — 6.10.30.00 (сборка 29), версия настроек iDRAC — 5.00.00.10

решение1

Я дважды проверил настройки сети iDRAC, шлюз был правильным (192.168.1.254). Я также искал и убедился, что iDRAC может пинговать шлюз ( racadmin ping 192.168.1.254когда я вошел в веб-интерфейс iDRAC в интрасети). Я также проверил конфигурацию порта pinhole маршрутизатора, которая тоже казалась нормальной. Я пытался получить удаленный доступ к веб-интерфейсу несколько раз и убедился, что журналы брандмауэра маршрутизатора не обнаружили эти пакеты и распознали как доступ pinhole.

Не уверен, что изменилось, но, возможно, мой браузер по умолчанию пытается использовать протокол http, когда видит IP-адрес (я подключаюсь к iDRAc удаленно только со статическим IP-адресом, без DNS-имени). Когда я вручную указал протокол https, вместо тайм-аута я получил сообщение об ошибке:

Плохой запрос

Ваш браузер отправил запрос, который этот сервер не смог понять

Кроме того, при попытке использовать ErrorDocument для обработки запроса файла возникла ошибка 400 Bad Request.

Это было и с Firefox, и с браузерами на базе Chromium. Затем я поискал это конкретное сообщение об ошибке и в статье Базы знаний нашел решение, которое помогло:Сбои подключения HTTP/HTTPS FQDN в прошивке iDRAC9 версии 5.10.00.000

Причина Веб-сервер в прошивке iDRAC9 версии 5.10.00.00 по умолчанию принудительно проверяет заголовок хоста HTTP / HTTPS. Разрешение По умолчанию iDRAC9 проверит заголовок хоста HTTP / HTTPS и сравнит его с заданными 'DNSRacName' и 'DNSDomainName'. Если значения не совпадают, iDRAC отклонит соединение HTTP / HTTPS. В iDRAC9 5.10.00.00 принудительное применение заголовка хоста можно отключить с помощью следующей команды RACADM.

#Disable host header check
racadm set idrac.webserver.HostHeaderCheck 0

Теперь мне интересно, представляет ли это какой-либо риск для безопасности. Мы получаем доступ к iDRAC с нефиксированных IP-адресов и обращаемся к нему по IP-адресу. Я могу придумать только REST-клиент, который бы внедрял требуемые HTTP-заголовки. Но, по крайней мере, теперь я могу получить доступ к веб-интерфейсу iDRAC.

решение2

Решение — использовать IP-адрес вместо FQDN. Тогда это работает.

Связанный контент