Risoluzione dei problemi di connessione della console Web di Cockpit su SUSE Linux Enterprise Server

Se la console Web di Cockpit non riesce a connettersi a un host SUSE Linux Enterprise Server (SLES), provare prima a connettersi https://SERVER_IP:9090, quindi verificare che cockpit.socketsia in ascolto e che il firewall consenta il servizio Cockpit nella zona utilizzata dall'interfaccia di rete del server. In un'installazione standard, questi controlli risolvono le cause più comuni: un URL o una porta errati, un socket inattivo, pacchetti Cockpit mancanti o una connessione in entrata bloccata.

Questa guida si applica ai sistemi SLES che utilizzano systemd e per i quali Cockpit è disponibile nei repository di prodotto configurati. La guida di SUSE per Cockpit su SLES 16 attualmente disponibile documenta i comandi di installazione e attivazione del socket descritti di seguito. La disponibilità e i nomi dei pacchetti possono variare a seconda del service pack, del modulo e del livello di supporto di SLES; pertanto, su un host SLES 15 meno recente, prima di considerare un errore di installazione come un problema del servizio, verificare che Cockpit sia disponibile nei repository SUSE abilitati.

Inizia dal sintomo

Utilizza l'errore visualizzato nel browser per circoscrivere la causa. Un timeout o un messaggio come "Impossibile raggiungere il sito" di solito indicano un problema di routing, regole del firewall o un listener non attivo. Una connessione rifiutata spesso significa che nessun servizio accetta connessioni sull'indirizzo e sulla porta selezionati. La visualizzazione della pagina di accesso di Cockpit indica che il servizio web è raggiungibile; un successivo errore di autenticazione è indice di un problema separato relativo all'account o alle policy. Un avviso relativo al certificato significa che la negoziazione HTTPS ha raggiunto il server, ma il browser non si fida del certificato o del suo nome.

Ad esempio, supponiamo che un amministratore non possa aprire un server il cui indirizzo è 192.0.2.25. Eseguire un test https://192.0.2.25:9090da una macchina che dovrebbe essere autorizzata ad amministrarlo. Cockpit normalmente utilizza HTTPS sulla porta 9090. Digitare solo l'indirizzo IP potrebbe aprire un servizio diverso e l'utilizzo di http://può portare a un reindirizzamento o a un avviso del browser anziché alla schermata di accesso prevista.

1. Verifica l'URL e la raggiungibilità

Conferma l'indirizzo IP corrente del server dalla console SLES o da un inventario attendibile e specifica esplicitamente la porta:

https://192.0.2.25:9090

Dal client, verificare se la porta TCP 9090 è raggiungibile. Su una workstation di amministrazione Linux con netcat installato, eseguire:

nc -vz 192.0.2.25 9090

Una connessione TCP riuscita dimostra solo che la porta è raggiungibile; non garantisce che l'accesso funzionerà. Un timeout suggerisce di verificare la zona firewall attiva del server, eventuali firewall di rete a monte, il routing e l'accesso VPN. Un rifiuto suggerisce di controllare il listener sull'host SLES. Se netcat non è disponibile, eseguire il test da un browser o utilizzare un altro strumento di connettività TCP approvato anziché installare un'utilità non approvata su un host di produzione.

2. Verificare che Cockpit sia installato e che il relativo socket sia attivo.

Connettiti tramite SSH o una console locale e ispeziona il socket. Cockpit normalmente utilizza l'attivazione del socket di systemd: systemd si mette in ascolto di una connessione in entrata per conto di Cockpit e avvia il servizio web su richiesta. Per questo motivo, l'unità chiave da ispezionare è solitamente cockpit.socket, non un'unità in esecuzione continua cockpit.service.

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

Cercare un socket attivo/in ascolto e un listener associato alla porta 9090. Se l'unità non è presente, Cockpit potrebbe non essere installato. In una versione SLES i cui repository abilitati forniscono il pattern Cockpit, la documentazione SUSE descrive come installarlo con:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Se Zypper segnala che il pattern non è stato trovato, verifica il prodotto, il service pack, i moduli abilitati, lo stato del repository e i diritti di supporto con il tuo amministratore SUSE. Non aggiungere un repository di terze parti non correlato solo per far sì che il comando abbia successo. Dopo aver verificato che Cockpit sia installato, abilita e avvia il suo socket:

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

Questa --nowopzione avvia immediatamente il socket e lo abilita per gli avvii futuri. Se systemd segnala un'unità non funzionante, esamina l'errore esatto prima di riavviarla ripetutamente:

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

3. Consentire a Cockpit di attraversare la zona firewall attiva

Un listener attivo può comunque risultare irraggiungibile se il firewall dell'host interrompe la connessione. Nelle versioni attuali, SLES utilizza firewalld per la gestione del firewall. Innanzitutto, identifica la zona attiva e l'interfaccia ad essa assegnata:

sudo firewall-cmd --get-active-zones

Aggiungi quindi il servizio Cockpit denominato alla zona che contiene l'interfaccia di gestione. Sostituisci publiccon la zona effettiva riportata sul tuo host:

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

Il comando finale dovrebbe riportare yes. Se l'interfaccia di rete si trova in una zona diversa, l'apertura del servizio in publicnon risolverà le regole di tale interfaccia. La documentazione di SUSE Cockpit utilizza il cockpitservizio firewalld; aprire il servizio specificato è preferibile rispetto all'apertura di tutto il traffico o alla disabilitazione del firewall. Verificare anche i gruppi di sicurezza cloud, i firewall perimetrali, le policy VPN e gli ACL di rete se la regola host è corretta ma il client continua ad andare in timeout.

Se l'immagine SLES utilizza una configurazione di gestione del firewall diversa, segui le policy di quel sistema anziché applicare i comandi firewalld senza criterio. Non svuotare le regole del firewall né disabilitare il firewall su un server di produzione amministrato da remoto: ciò potrebbe esporre i servizi e interrompere la configurazione di gestione corrente.

4. Distinguere un errore di connessione da un problema di certificato o di accesso.

Una volta caricata la pagina di accesso, il percorso di rete verso Cockpit risulta funzionante. Cockpit normalmente si aspetta che le connessioni del browser utilizzino HTTPS e presenta un certificato TLS. Un avviso relativo a un certificato autofirmato o a una mancata corrispondenza del nome non significa che il socket sia inattivo. Per un host di laboratorio, verificare l'impronta digitale tramite un canale attendibile prima di accettare l'avviso. Per i sistemi gestiti, installare un certificato il cui nome soggetto corrisponda al nome host utilizzato dagli amministratori e la cui catena di certificati sia considerata attendibile dai loro browser.

Se la pagina di accesso viene visualizzata ma le credenziali vengono rifiutate, verificare il nome utente, la password, lo stato dell'account e i criteri di autenticazione del server. Cockpit generalmente si autentica tramite account di sistema; non si tratta di un database utenti separato. Non inserire password nei comandi o nei log durante la risoluzione dei problemi. Se la pagina si carica ma l'interfaccia rimane vuota o si disconnette dopo l'accesso, esaminare la console per sviluppatori del browser e i log recenti di Cockpit. Anche un proxy inverso può causare errori se non supporta le connessioni WebSocket o inoltra informazioni errate sul protocollo o sull'host.

5. Rivedi i registri e le impostazioni del proxy quando i parametri di base sono stati superati

Cattura un breve intervallo di log durante un nuovo tentativo di connessione:

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

Cerca errori di bind, errori di autorizzazione o di certificato e messaggi che coincidono con l'orario del test. Se il server è in ascolto localmente ma un client remoto non riesce a connettersi, analizza il percorso di rete e la zona firewalld prima di modificare la configurazione di Cockpit. Se l'accesso diretto funziona ma l'accesso tramite proxy fallisce, confronta temporaneamente la connessione tramite un percorso diretto consentito, quindi verifica il supporto per l'aggiornamento WebSocket del proxy e le intestazioni inoltrate. Evita di modificare le impostazioni di origine o TLS di Cockpit come primo passo; impostazioni di attendibilità del proxy errate possono compromettere la sicurezza.

Verificare la riparazione

Dopo aver apportato una modifica alla volta, verifica i seguenti risultati:

• systemctl status cockpit.socketMostra il socket attivo e in ascolto.
• L'host SLES ha un listener sulla porta prevista, normalmente TCP 9090.
• La regola del firewall è presente nella zona assegnata all'interfaccia di gestione.
• Il client può raggiungere il server all'indirizzo https://SERVER_IP:9090e visualizzare la pagina di accesso a Cockpit.
• Dopo l'autenticazione, la pagina rimane connessa e il registro recente non contiene errori di avvio o di connessione corrispondenti.

Se il socket è attivo e i controlli locali hanno esito positivo, ma i test TCP remoti continuano a scadere, è probabile che il problema rimanente sia esterno a Cockpit, ad esempio un firewall a monte, un percorso di rete, un record DNS o una regola VPN. Se il servizio non funziona su un sistema SLES altrimenti supportato, salvare lo stato dell'unità e l'output del journal e consultare la documentazione SUSE o il canale di supporto per la configurazione esatta del service pack, anziché applicare correzioni destinate a un'altra distribuzione.

Riferimenti ufficiali

• SUSE: Amministrazione di SUSE Linux Enterprise Server tramite Cockpit
• Progetto Cockpit: avvio e attivazione del socket systemd
• Progetto Cockpit: porta e indirizzo TCP
• Progetto Cockpit: HTTPS e certificati
• Progetto Cockpit: FAQ sulla risoluzione dei problemi
• SUSE: configurazione del firewall SLES 15 SP5 e zone firewalld