☰

Warum kann ich nicht remote auf iDRAC9 zugreifen?

tag-icon • tag-icon router rdp redirection drac
Warum kann ich nicht remote auf iDRAC9 zugreifen?

Ich habe einen Dell PowerEdge T350 mit einem iDRAC9 Basic. Der Server ist mit einem Switch verbunden, der wiederum mit einem Router verbunden ist, der wiederum mit dem Internet verbunden ist. Ganz einfach. Sowohl die NIC1 des Servers als auch die UTP-LAN-Karte des iDRAC sind mit dem Switch verbunden. Ich habe den iDRAC aktiviert und kann von einem anderen Host, der mit demselben Switch verbunden ist (auch bekannt als Intranet), auf die Web-GUI zugreifen.

Für beide LAN-Schnittstellen des Servers sind statische Intranet-IPs konfiguriert (im Bereich 192.168.1.x) und kein DHCP-d, da wir für die Portübersetzungen auf dem Router besser eine feste IP haben. Ich habe die Portübersetzungen auf dem Router so konfiguriert, dass auf zwei Dienste remote zugegriffen werden kann: RDP und iDRAC. Das RDP ist das Server-Betriebssystem selbst.

Hier kommt der interessante Teil:

  1. Ich kann mit RDP über das Intranet auf das Server-Betriebssystem zugreifen
  2. Ich kann per RDP remote auf das Server-Betriebssystem zugreifen
  3. Ich kann über das Intranet auf die iDRAC-Web-GUI zugreifen
  4. Ich kann nicht remote auf die iDRAC-Web-GUI zugreifen

Ich habe die iDRAC-Portumleitung (oder wir können es Firewall-Pinhole nennen) auf die gleiche Weise konfiguriert wie beim RDP. Obwohl das RDP sowohl TCP- als auch UDP-3389-Portumleitung benötigt. Der iDRAC benötigt nur TCP-443-Portumleitung.

Fragen:

  1. Gibt es auf dem iDRAC einen Schalter oder eine Konfigurationsoption, die den Intranetzugriff standardmäßig verhindert? (Allerdings findet eine Adressübersetzung/NAT durch den Router statt, sodass diese Frage möglicherweise nicht einmal Sinn ergibt?)
  2. Der fragliche Router ist ein PACE 5268AC FXN. Ich kann im Handbuch nichts finden, das darauf hinweist, dass er eine Umleitung von 3389 (oder auch 3390, da ich auch das RDP einer anderen Maschine geknackt habe) zulässt, aber mit HTTPS fehlschlägt. Ich sehe im Firewall-Protokoll nichts Nützliches, das helfen würde. Es scheint, dass die eingehenden Intranet-443-Pakete den Router irgendwie nicht einmal erreichen? Ich verstehe es nicht.
  3. Ich habe auch 33443 -> 443 und andere Weiterleitungsarten anstelle von 443 -> 443 ausprobiert, aber das hat auch nicht funktioniert.
  4. Ich füge auch hinzu, dass das SSL-Zertifikat des iDRAC ein Blindgänger (nicht gültig) ist, aber es scheint, dass das Ding schon früher fehlgeschlagen ist. Der ISP ist AT&T.

Zur Information: Meine iDRAC Firmware-Version ist 6.10.30.00 (Build 29), iDRAC-Einstellungen Version 5.00.00.10

Antwort1

Ich habe meine iDRAC-Netzwerkeinstellungen doppelt überprüft, das Gateway war korrekt (192.168.1.254). Ich habe auch gesucht und überprüft, ob der iDRAC das Gateway anpingen kann ( racadmin ping 192.168.1.254als ich mich im Intranet bei der iDRAC-Web-GUI angemeldet habe). Ich habe auch die Port-Pinhole-Konfiguration des Routers überprüft, die ebenfalls in Ordnung zu sein schien. Ich habe ein paar Mal versucht, remote auf die Web-GUI zuzugreifen, und habe überprüft, dass die Firewall-Protokolle des Routers diese Pakete nicht enthalten und als Pinhole-Zugriff erkannt haben.

Ich bin nicht sicher, was sich geändert hat, aber vielleicht versucht mein Browser standardmäßig das HTTP-Protokoll, wenn er eine IP-Adresse sieht (ich greife remote nur mit einer statischen IP-Adresse auf den iDRAc zu, ohne DNS-Namen). Wenn ich das HTTPS-Protokoll manuell eingebe, erhalte ich statt einer Zeitüberschreitung eine Fehlermeldung:

Ungültige Anforderung

Ihr Browser hat eine Anfrage gesendet, die dieser Server nicht verstehen konnte

Darüber hinaus ist beim Versuch, die Dateianforderung mithilfe eines ErrorDocument zu verarbeiten, ein 400 Bad Request-Fehler aufgetreten.

Dies war sowohl bei Firefox- als auch bei Chromium-basierten Browsern der Fall. Dann suchte ich nach dieser spezifischen Fehlermeldung und fand in einem Knowledge Base-Artikel eine Lösung, die half:HTTP/HTTPS FQDN-Verbindungsfehler bei iDRAC9-Firmwareversion 5.10.00.000

Ursache Der Webserver in der iDRAC9-Firmwareversion 5.10.00.00 erzwingt standardmäßig eine HTTP-/HTTPS-Host-Header-Prüfung. Auflösung Standardmäßig prüft iDRAC9 den HTTP-/HTTPS-Host-Header und vergleicht ihn mit dem definierten „DNSRacName“ und „DNSDomainName“. Wenn die Werte nicht übereinstimmen, lehnt iDRAC die HTTP-/HTTPS-Verbindung ab. In iDRAC9 5.10.00.00 kann diese Host-Header-Durchsetzung mit dem folgenden RACADM-Befehl deaktiviert werden.

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

Jetzt frage ich mich, ob dies ein Sicherheitsrisiko darstellt. Wir greifen von nicht festen IPs auf den iDRAC zu und adressieren ihn mit einer IP-Adresse. Mir fällt nur ein REST-Client ein, der die erforderlichen HTTP-Header einfügen würde. Aber zumindest kann ich jetzt auf die iDRAC-Web-GUI zugreifen.

Antwort2

Eine Lösung besteht darin, die IP-Adresse anstelle des FQDN zu verwenden. Dann funktioniert es.

verwandte Informationen