Behebung von Verbindungsproblemen der Cockpit-Webkonsole auf SUSE Linux Enterprise Server

Wenn die Cockpit-Webkonsole keine Verbindung zu einem SUSE Linux Enterprise Server (SLES)-Host herstellen kann, versuchen Sie zunächst https://SERVER_IP:9090, die Verbindung herzustellen. Überprüfen Sie anschließend, cockpit.socketob der Dienst aktiv ist und die Firewall den Cockpit-Dienst in der Zone zulässt, die von der Netzwerkschnittstelle des Servers verwendet wird. Bei einer Standardinstallation beheben diese Prüfungen die häufigsten Ursachen: eine falsche URL oder einen falschen Port, einen inaktiven Socket, fehlende Cockpit-Pakete oder eine blockierte eingehende Verbindung.

Diese Anleitung gilt für SLES-Systeme mit systemd, auf denen Cockpit über die konfigurierten Produkt-Repositories verfügbar ist. Die aktuelle Cockpit-Anleitung von SUSE für SLES 16 beschreibt die unten aufgeführten Befehle für die Musterinstallation und Socket-Aktivierung. Paketverfügbarkeit und -namen können je nach SLES-Service-Pack, Modul und Support-Berechtigung variieren. Prüfen Sie daher auf einem älteren SLES-15-Host, ob Cockpit in den aktivierten SUSE-Repositories verfügbar ist, bevor Sie einen Installationsfehler als Servicefehler behandeln.

Beginnen Sie mit dem Symptom.

Nutzen Sie die Fehlermeldung im Browser, um die Ursache einzugrenzen. Eine Zeitüberschreitung oder die Meldung „Website nicht erreichbar“ deutet in der Regel auf ein Problem mit dem Routing, Firewall-Regeln oder einem nicht aktiven Listener hin. Eine abgelehnte Verbindung bedeutet oft, dass an der ausgewählten Adresse und dem Port keine Verbindungen akzeptiert werden. Eine Cockpit-Anmeldeseite zeigt an, dass der Webdienst erreichbar ist; ein späterer Authentifizierungsfehler deutet auf ein separates Konto- oder Richtlinienproblem hin. Eine Zertifikatswarnung bedeutet, dass die HTTPS-Aushandlung den Server erreicht hat, der Browser dem Zertifikat oder dessen Namen jedoch nicht vertraut.

Angenommen, ein Administrator kann einen Server mit der Adresse nicht öffnen 192.0.2.25. Testen Sie dies https://192.0.2.25:9090von einem Rechner aus, der die Berechtigung zur Administration haben sollte. Cockpit verwendet normalerweise HTTPS auf Port 9090. Die Eingabe der IP-Adresse allein kann einen anderen Dienst öffnen, und die Verwendung von http://kann zu einer Weiterleitung oder einer Browserwarnung anstelle der erwarteten Anmeldeansicht führen.

1. URL und Erreichbarkeit prüfen

Bestätigen Sie die aktuelle Serveradresse in der SLES-Konsole oder einem vertrauenswürdigen Inventarverzeichnis und geben Sie den Port explizit an:

https://192.0.2.25:9090

Testen Sie vom Client aus, ob der TCP-Port 9090 erreichbar ist. Führen Sie dazu auf einer Linux-Administrations-Workstation mit installiertem netcat folgenden Befehl aus:

nc -vz 192.0.2.25 9090

Eine erfolgreiche TCP-Verbindung beweist lediglich, dass der Port erreichbar ist; sie garantiert nicht, dass die Anmeldung funktioniert. Ein Timeout deutet darauf hin, dass die aktive Firewall-Zone des Servers, etwaige vorgelagerte Netzwerk-Firewalls, das Routing und der VPN-Zugang überprüft werden sollten. Eine Ablehnung deutet darauf hin, dass der Listener auf dem SLES-Host überprüft werden sollte. Falls netcat nicht verfügbar ist, testen Sie die Verbindung über einen Browser oder verwenden Sie ein anderes zugelassenes TCP-Verbindungstool, anstatt ein nicht zugelassenes Tool auf einem Produktivsystem zu installieren.

2. Prüfen Sie, ob Cockpit installiert und die zugehörige Steckdose aktiv ist.

Stellen Sie eine Verbindung per SSH oder über eine lokale Konsole her und überprüfen Sie den Socket. Cockpit verwendet normalerweise die Socket-Aktivierung von systemd: systemd wartet im Auftrag von Cockpit auf eingehende Verbindungen und startet den Webdienst bei Bedarf. Daher ist die zu untersuchende Einheit üblicherweise die Socket-Aktivierung selbst cockpit.socket, nicht ein permanent laufender Prozess cockpit.service.

sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'

Suchen Sie nach einem aktiven/lauschenden Socket und einem an Port 9090 gebundenen Listener. Falls die Einheit fehlt, ist Cockpit möglicherweise nicht installiert. Bei einer SLES-Version, deren aktivierte Repositories das Cockpit-Muster bereitstellen, dokumentiert SUSE die Installation wie folgt:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Meldet Zypper, dass das Muster nicht gefunden werden kann, überprüfen Sie mit Ihrem SUSE-Administrator das Produkt, das Service Pack, die aktivierten Module, den Repository-Status und die Supportberechtigung. Fügen Sie kein nicht zugehöriges Drittanbieter-Repository hinzu, nur um den Befehl erfolgreich auszuführen. Nachdem Sie die Installation von Cockpit bestätigt haben, aktivieren und starten Sie dessen Socket.

sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

Diese --nowOption startet den Socket sofort und aktiviert ihn für zukünftige Systemstarts. Falls systemd einen Fehler meldet, überprüfen Sie die genaue Fehlermeldung, bevor Sie den Dienst wiederholt neu starten.

sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager

3. Cockpit durch die aktive Firewall-Zone zulassen

Ein aktiver Listener kann weiterhin unerreichbar sein, wenn die Host-Firewall die Verbindung trennt. SLES verwendet in aktuellen Versionen firewalld für die Firewall-Verwaltung. Identifizieren Sie zunächst die aktive Zone und die ihr zugewiesene Schnittstelle:

sudo firewall-cmd --get-active-zones

Fügen Sie anschließend den benannten Cockpit-Dienst der Zone hinzu, die die Verwaltungsschnittstelle enthält. Ersetzen Sie „ publicZone“ durch die tatsächliche Zone, die auf Ihrem Host gemeldet wird:

sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit

Der letzte Befehl sollte eine Meldung ausgeben yes. Befindet sich die Netzwerkschnittstelle in einer anderen Zone, publicbehebt das Öffnen des Dienstes in dieser Zone die Regeln dieser Schnittstelle nicht. Die SUSE Cockpit-Dokumentation verwendet den cockpitfirewalld-Dienst; das Öffnen des genannten Dienstes ist dem Öffnen des gesamten Datenverkehrs oder dem Deaktivieren der Firewall vorzuziehen. Überprüfen Sie außerdem Cloud-Sicherheitsgruppen, Perimeter-Firewalls, VPN-Richtlinien und Netzwerk-ACLs, falls die Host-Regel korrekt ist, der Client aber weiterhin eine Zeitüberschreitung meldet.

Wenn Ihr SLES-Image eine andere Firewall-Verwaltungskonfiguration verwendet, befolgen Sie die Richtlinien dieses Systems, anstatt firewalld-Befehle wahllos anzuwenden. Löschen Sie keine Firewall-Regeln und deaktivieren Sie die Firewall nicht auf einem remote verwalteten Produktionsserver: Dies kann Dienste gefährden und Ihren aktuellen Verwaltungsablauf unterbrechen.

4. Trennen Sie einen Verbindungsfehler von einem Zertifikats- oder Anmeldeproblem.

Sobald die Anmeldeseite geladen ist, funktioniert die Netzwerkverbindung zu Cockpit. Cockpit erwartet normalerweise HTTPS-Verbindungen über den Browser und stellt ein TLS-Zertifikat bereit. Eine Warnung bezüglich eines selbstsignierten Zertifikats oder einer Namensabweichung bedeutet nicht, dass die Verbindung unterbrochen ist. Bei einem Testsystem sollte der Fingerabdruck über einen vertrauenswürdigen Kanal überprüft werden, bevor die Warnung akzeptiert wird. Bei verwalteten Systemen muss ein Zertifikat installiert werden, dessen Subjektname mit dem Hostnamen der Administratoren übereinstimmt und dessen Zertifikatskette von deren Browsern als vertrauenswürdig eingestuft wird.

Wenn die Anmeldeseite erscheint, die Anmeldedaten aber abgelehnt werden, überprüfen Sie Benutzername, Passwort, Kontostatus und die Authentifizierungsrichtlinie des Servers. Cockpit authentifiziert sich in der Regel über Systemkonten; es handelt sich nicht um eine separate Benutzerdatenbank. Geben Sie während der Fehlersuche keine Passwörter in Befehlen oder Protokollen ein. Wenn die Seite geladen wird, die Benutzeroberfläche aber leer bleibt oder die Verbindung nach der Anmeldung abbricht, überprüfen Sie die Entwicklerkonsole des Browsers und die letzten Cockpit-Protokolle. Ein Reverse-Proxy kann ebenfalls Fehler verursachen, wenn er keine WebSocket-Verbindungen unterstützt oder das falsche Protokoll oder falsche Hostinformationen weiterleitet.

5. Überprüfen Sie die Protokolle und Proxy-Einstellungen, sobald die grundlegenden Tests erfolgreich abgeschlossen sind.

Erfassen Sie ein kurzes Protokollfenster während eines neuen Verbindungsversuchs:

sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager

Achten Sie auf Bindungsfehler, Berechtigungs- oder Zertifikatsfehler sowie auf Meldungen, die mit dem Testzeitpunkt übereinstimmen. Wenn der Server lokal lauscht, ein Remote-Client aber keine Verbindung herstellen kann, untersuchen Sie den Netzwerkpfad und die Firewall-Zone, bevor Sie die Cockpit-Konfiguration ändern. Funktioniert der direkte Zugriff, der Zugriff über einen Proxy jedoch nicht, vergleichen Sie vorübergehend über eine zulässige direkte Route und überprüfen Sie anschließend die Unterstützung für WebSocket-Upgrades und die weitergeleiteten Header des Proxys. Ändern Sie nicht als ersten Schritt die Ursprungs- oder TLS-Einstellungen von Cockpit; falsche Proxy-Vertrauenseinstellungen können die Sicherheit beeinträchtigen.

Überprüfen Sie die Reparatur.

Nachdem Sie jeweils eine Änderung vorgenommen haben, überprüfen Sie diese Ergebnisse:

• systemctl status cockpit.socketZeigt an, dass die Socket-Verbindung aktiv ist und auf eingehende Nachrichten wartet.
• Der SLES-Host hat einen Listener auf dem erwarteten Port, normalerweise TCP 9090.
• Die Firewall-Regel ist in der Zone vorhanden, die der Verwaltungsschnittstelle zugewiesen ist.
• Der Client kann den Server unter der angegebenen Adresse erreichen https://SERVER_IP:9090und sieht die Cockpit-Anmeldeseite.
• Nach der Authentifizierung bleibt die Seite verbunden und im aktuellen Protokoll sind keine entsprechenden Start- oder Verbindungsfehler verzeichnet.

Wenn die Socket-Verbindung aktiv ist und lokale Prüfungen erfolgreich sind, aber Remote-TCP-Tests weiterhin ein Timeout verursachen, liegt die verbleibende Fehlerursache wahrscheinlich außerhalb von Cockpit selbst, beispielsweise in einer vorgelagerten Firewall, einer Netzwerkroute, einem DNS-Eintrag oder einer VPN-Regel. Falls der Dienst auf einem ansonsten unterstützten SLES-System ausfällt, speichern Sie den Gerätestatus und die Journalausgabe und prüfen Sie die SUSE-Dokumentation oder den Supportkanal auf die genaue Service-Pack-Konfiguration, anstatt Korrekturen anzuwenden, die für eine andere Distribution vorgesehen sind.

Offizielle Referenzen

• SUSE: Administration von SUSE Linux Enterprise Server mit Cockpit
• Cockpit-Projekt: Startvorgang und Aktivierung des systemd-Sockets
• Cockpit-Projekt: TCP-Port und Adresse
• Cockpit-Projekt: HTTPS und Zertifikate
• Cockpit-Projekt: Häufig gestellte Fragen zur Fehlerbehebung
• SUSE: SLES 15 SP5 Firewall-Konfiguration und firewalld-Zonen