Naprawa braku połączenia konsoli internetowej Cockpit na serwerze SUSE Linux Enterprise

Jeśli konsola internetowa Cockpit nie łączy się z hostem SUSE Linux Enterprise Server (SLES), najpierw spróbuj https://SERVER_IP:9090, a następnie sprawdź, czy cockpit.socketnasłuchuje i czy zapora sieciowa zezwala na usługę Cockpit w strefie używanej przez interfejs sieciowy serwera. W standardowej instalacji te sprawdzenia rozwiązują najczęstsze przyczyny: nieprawidłowy adres URL lub port, nieaktywne gniazdo, brakujące pakiety Cockpit lub zablokowane połączenie przychodzące.

Niniejszy przewodnik dotyczy systemów SLES korzystających z systemd i posiadających Cockpit dostępny w skonfigurowanych repozytoriach produktów. Aktualny przewodnik SUSE dla Cockpitu SLES 16 dokumentuje poniższe polecenia instalacji wzorca i aktywacji gniazda. Dostępność i nazwy pakietów mogą się różnić w zależności od pakietu serwisowego, modułu i uprawnień wsparcia SLES, dlatego na starszym hoście SLES 15 należy sprawdzić, czy Cockpit jest oferowany przez włączone repozytoria SUSE, zanim potraktuje się błąd instalacji jako błąd usługi.

Zacznij od objawu

Użyj błędu w przeglądarce, aby zawęzić przyczynę. Przekroczenie limitu czasu lub komunikat „nie można nawiązać połączenia z witryną” zazwyczaj wskazuje na routing, reguły zapory sieciowej lub nieaktywny odbiornik. Odrzucone połączenie często oznacza, że ​​na wybranym adresie i porcie nic nie akceptuje połączeń. Strona logowania w Cockpit oznacza, że ​​usługa internetowa jest dostępna; późniejszy błąd uwierzytelniania to problem z oddzielnym kontem lub polityką. Ostrzeżenie o certyfikacie oznacza, że ​​negocjacja HTTPS dotarła do serwera, ale przeglądarka nie ufa certyfikatowi ani jego nazwie.

Załóżmy na przykład, że administrator nie może otworzyć serwera o adresie 192.0.2.25. Przetestuj https://192.0.2.25:9090z komputera, który powinien mieć uprawnienia do administrowania nim. Cockpit zazwyczaj używa protokołu HTTPS na porcie 9090. Wpisanie samego adresu IP może spowodować otwarcie innej usługi, a użycie http://może spowodować przekierowanie lub ostrzeżenie przeglądarki zamiast oczekiwanego widoku logowania.

1. Sprawdź adres URL i dostępność

Potwierdź aktualny adres serwera z poziomu konsoli SLES lub zaufanego inwentarza i jawnie uwzględnij port:

https://192.0.2.25:9090

Z poziomu klienta sprawdź, czy port TCP 9090 jest osiągalny. Na stacji roboczej z systemem Linux i zainstalowanym programem netcat uruchom:

nc -vz 192.0.2.25 9090

Udane połączenie TCP dowodzi jedynie, że port jest osiągalny; nie dowodzi, że logowanie będzie działać. Przekroczenie limitu czasu sugeruje sprawdzenie aktywnej strefy zapory sieciowej serwera, zapory sieciowej nadrzędnej, routingu i dostępu VPN. Odmowa sugeruje sprawdzenie nasłuchiwacza na hoście SLES. Jeśli netcat jest niedostępny, przetestuj połączenie z poziomu przeglądarki lub użyj innego zatwierdzonego narzędzia do obsługi połączeń TCP, zamiast instalować niezatwierdzone narzędzie na hoście produkcyjnym.

2. Sprawdź, czy kokpit jest zainstalowany i czy jego gniazdo jest aktywne

Połącz się przez SSH lub konsolę lokalną i sprawdź gniazdo. Cockpit zazwyczaj korzysta z aktywacji gniazda systemd: systemd nasłuchuje połączenia przychodzącego w imieniu Cockpit i uruchamia usługę sieciową na żądanie. Z tego powodu kluczową jednostką do sprawdzenia jest zazwyczaj cockpit.socket, a nie stale działający cockpit.service.

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

Poszukaj aktywnego/nasłuchującego gniazda i nasłuchiwacza powiązanego z portem 9090. Jeśli brakuje jednostki, Cockpit może nie być zainstalowany. W wersji SLES, której włączone repozytoria udostępniają wzorzec Cockpit, dokumentacja SUSE dotycząca instalacji zawiera:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Jeśli Zypper zgłasza, że ​​nie można znaleźć wzorca, sprawdź produkt, dodatek Service Pack, włączone moduły, stan repozytorium i uprawnienia do wsparcia u administratora SUSE. Nie dodawaj niepowiązanego repozytorium innej firmy tylko po to, aby polecenie się powiodło. Po potwierdzeniu instalacji Cockpitu, włącz i uruchom jego gniazdo:

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

Ta --nowopcja natychmiast uruchamia gniazdo i umożliwia jego uruchomienie w przyszłości. Jeśli systemd zgłosi awarię jednostki, sprawdź dokładny błąd przed ponownym jej uruchomieniem:

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

3. Zezwól Kokpitowi na przejście przez aktywną strefę zapory sieciowej

Aktywny odbiornik może nadal być niedostępny, jeśli zapora hosta zerwie połączenie. W obecnych wersjach SLES używa firewalld do zarządzania zaporą. Najpierw zidentyfikuj aktywną strefę i przypisany do niej interfejs:

sudo firewall-cmd --get-active-zones

Następnie dodaj nazwaną usługę Cockpit do strefy zawierającej interfejs zarządzania. Zastąp ją publicrzeczywistą strefą zgłoszoną na hoście:

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

Ostatnie polecenie powinno zwrócić yes. Jeśli interfejs sieciowy znajduje się w innej strefie, otwarcie usługi w publicnie naprawi reguł tego interfejsu. Dokumentacja SUSE Cockpit korzysta z cockpitusługi firewalld; otwarcie wskazanej usługi jest lepsze niż otwarcie całego ruchu lub wyłączenie zapory. Sprawdź również grupy zabezpieczeń w chmurze, zapory obwodowe, zasady VPN i listy kontroli dostępu sieci, jeśli reguła hosta jest poprawna, ale klient nadal przekracza limit czasu.

Jeśli Twój obraz SLES korzysta z innej konfiguracji zarządzania zaporą sieciową, postępuj zgodnie z zasadami obowiązującymi dla tego systemu, zamiast bezmyślnie stosować polecenia firewalld. Nie opróżniaj reguł zapory ani nie wyłączaj zapory na zdalnie administrowanym serwerze produkcyjnym: może to spowodować ujawnienie usług i przerwanie bieżącej ścieżki zarządzania.

4. Oddziel błąd połączenia od problemu z certyfikatem lub logowaniem

Po załadowaniu strony logowania ścieżka sieciowa do Cockpitu działa. Cockpit zazwyczaj oczekuje połączeń z przeglądarki za pomocą protokołu HTTPS i prezentuje certyfikat TLS. Ostrzeżenie o certyfikacie z podpisem własnym lub niezgodności nazw nie oznacza, że ​​gniazdo jest nieaktywne. W przypadku hosta laboratoryjnego należy zweryfikować odcisk palca za pomocą zaufanego kanału przed zaakceptowaniem ostrzeżenia. W przypadku systemów zarządzanych należy zainstalować certyfikat, którego nazwa podmiotu jest zgodna z nazwą hosta używaną przez administratorów i którego łańcuch jest zaufany przez ich przeglądarki.

Jeśli pojawi się strona logowania, ale dane uwierzytelniające zostaną odrzucone, sprawdź nazwę użytkownika, hasło, stan konta oraz politykę uwierzytelniania serwera. Cockpit zazwyczaj uwierzytelnia konta systemowe; nie jest to oddzielna baza danych użytkowników. Podczas rozwiązywania problemów nie należy umieszczać haseł w poleceniach ani logach. Jeśli strona się załaduje, ale interfejs pozostaje pusty lub rozłącza się po zalogowaniu, sprawdź konsolę programisty przeglądarki i ostatnie logi Cockpit. Odwrotny serwer proxy może również powodować błędy, jeśli nie obsługuje połączeń WebSocket lub przekazuje nieprawidłowe informacje o protokole lub hoście.

5. Przejrzyj dzienniki i ustawienia proxy, gdy podstawy zostaną zaliczone

Zarejestruj krótkie okno dziennika podczas próby nawiązania nowego połączenia:

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

Poszukaj błędów powiązań, uprawnień lub certyfikatów oraz komunikatów zgodnych z czasem testu. Jeśli serwer nasłuchuje lokalnie, ale klient zdalny nie może się połączyć, sprawdź ścieżkę sieciową i strefę firewalld przed zmianą konfiguracji Cockpit. Jeśli dostęp bezpośredni działa, ale dostęp przez serwer proxy nie działa, tymczasowo porównaj przez dozwoloną trasę bezpośrednią, a następnie sprawdź obsługę aktualizacji WebSocket przez serwer proxy i przekazane nagłówki. Unikaj zmiany ustawień źródła lub TLS w Cockpit na samym początku; nieprawidłowe ustawienia zaufania serwera proxy mogą osłabić bezpieczeństwo.

Zweryfikuj naprawę

Po wprowadzeniu jednej zmiany, zweryfikuj poniższe wyniki:

• systemctl status cockpit.socketpokazuje, że gniazdo jest aktywne i nasłuchuje.
• Host SLES ma nasłuchiwacz na oczekiwanym porcie, zwykle TCP 9090.
• Reguła zapory jest obecna w strefie przypisanej do interfejsu zarządzania.
• Klient może połączyć się z serwerem pod adresem https://SERVER_IP:9090i zobaczyć stronę logowania do Cockpitu.
• Po uwierzytelnieniu strona pozostaje połączona, a ostatni dziennik nie zawiera żadnych pasujących błędów uruchamiania lub połączenia.

Jeśli gniazdo jest aktywne i lokalne testy kończą się powodzeniem, ale zdalne testy TCP nadal przekraczają limit czasu, pozostała usterka prawdopodobnie leży poza samym Cockpitem, np. w zaporze sieciowej, trasie sieciowej, rekordzie DNS lub regule VPN. Jeśli usługa nie działa w obsługiwanym systemie SLES, zapisz status urządzenia i dane wyjściowe dziennika oraz sprawdź dokumentację SUSE lub kanał wsparcia technicznego pod kątem dokładnej konfiguracji Service Pack, zamiast stosować poprawki przeznaczone dla innej dystrybucji.

Oficjalne referencje

• SUSE: Administrowanie systemem SUSE Linux Enterprise Server za pomocą Cockpit
• Projekt kokpitu: uruchomienie i aktywacja gniazda systemd
• Projekt kokpitu: port i adres TCP
• Projekt kokpitu: HTTPS i certyfikaty
• Projekt kokpitu: często zadawane pytania dotyczące rozwiązywania problemów
• SUSE: Konfiguracja zapory SLES 15 SP5 i strefy firewalld