Solucionar el problema de conexión de la consola web Cockpit en SUSE Linux Enterprise Server.

Si la consola web de Cockpit no se conecta a un host SUSE Linux Enterprise Server (SLES), primero intente https://SERVER_IP:9090verificar que cockpit.socketesté escuchando y que el firewall permita el servicio Cockpit en la zona utilizada por la interfaz de red del servidor. En una instalación estándar, estas comprobaciones resuelven las causas más comunes: una URL o puerto incorrectos, un socket inactivo, paquetes de Cockpit faltantes o una conexión entrante bloqueada.

Esta guía se aplica a los sistemas SLES que utilizan systemd y tienen Cockpit disponible en sus repositorios de productos configurados. La guía actual de Cockpit para SLES 16 de SUSE documenta los comandos de instalación y activación de sockets que se describen a continuación. La disponibilidad y los nombres de los paquetes pueden variar según el Service Pack, el módulo y el nivel de soporte de SLES, por lo que en un host SLES 15 anterior, confirme que Cockpit está disponible en sus repositorios SUSE habilitados antes de considerar un error de instalación como un fallo del servicio.

Comience con el síntoma.

Utilice el error del navegador para acotar la causa. Un tiempo de espera agotado o el mensaje "no se puede acceder al sitio" generalmente indican problemas de enrutamiento, reglas de firewall o un servidor de escucha inactivo. Una conexión rechazada suele significar que ningún servidor acepta conexiones en la dirección y el puerto seleccionados. Una página de inicio de sesión de Cockpit indica que el servicio web es accesible; un error de autenticación posterior indica un problema de cuenta o política independiente. Una advertencia de certificado significa que la negociación HTTPS llegó al servidor, pero el navegador no confía en el certificado ni en su nombre.

Por ejemplo, supongamos que un administrador no puede abrir un servidor cuya dirección es 192.0.2.25. Pruebe https://192.0.2.25:9090desde una máquina que sí debería tener permisos para administrarlo. Cockpit normalmente usa HTTPS en el puerto 9090. Escribir solo la dirección IP puede abrir un servicio diferente, y usar http://puede provocar una redirección o una advertencia del navegador en lugar de la pantalla de inicio de sesión esperada.

1. Comprueba la URL y la accesibilidad.

Confirme la dirección actual del servidor desde la consola SLES o un inventario de confianza, e incluya el puerto explícitamente:

https://192.0.2.25:9090

Desde el cliente, compruebe si el puerto TCP 9090 es accesible. En una estación de trabajo de administración Linux con netcat instalado, ejecute:

nc -vz 192.0.2.25 9090

Una conexión TCP exitosa solo demuestra que el puerto es accesible; no garantiza que el inicio de sesión funcione. Un tiempo de espera agotado sugiere revisar la zona de firewall activa del servidor, cualquier firewall de red ascendente, el enrutamiento y el acceso VPN. Un rechazo sugiere revisar el oyente en el host SLES. Si netcat no está disponible, realice la prueba desde un navegador o utilice otra herramienta de conectividad TCP aprobada en lugar de instalar una utilidad no aprobada en un host de producción.

2. Confirme que Cockpit esté instalado y que su socket esté activo.

Conéctese a través de SSH o una consola local e inspeccione el socket. Cockpit normalmente utiliza la activación de sockets de systemd: systemd escucha una conexión entrante en nombre de Cockpit e inicia el servicio web bajo demanda. Debido a esto, la unidad clave a inspeccionar suele ser cockpit.socket, no un que se ejecuta continuamente cockpit.service.

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

Busque un socket activo/en escucha y un oyente vinculado al puerto 9090. Si falta la unidad, es posible que Cockpit no esté instalado. En una versión de SLES cuyos repositorios habilitados proporcionan el patrón de Cockpit, SUSE documenta su instalación con:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Si Zypper indica que no se puede encontrar el patrón, verifique el producto, el paquete de servicio, los módulos habilitados, el estado del repositorio y la autorización de soporte con su administrador de SUSE. No agregue un repositorio de terceros no relacionado solo para que el comando se ejecute correctamente. Después de confirmar que Cockpit está instalado, habilite e inicie su socket:

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

Esta --nowopción inicia el socket inmediatamente y lo habilita para arranques futuros. Si systemd informa de una unidad fallida, examine el error exacto antes de reiniciarlo repetidamente:

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

3. Permitir que Cockpit atraviese la zona de firewall activa.

Un oyente activo puede seguir siendo inaccesible si el firewall del host interrumpe la conexión. SLES utiliza firewalld para la administración del firewall en las versiones actuales. Primero, identifique la zona activa y la interfaz asignada a ella:

sudo firewall-cmd --get-active-zones

Luego, agregue el servicio Cockpit con nombre a la zona que contiene la interfaz de administración. Reemplace publiccon la zona real que se informa en su host:

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

El comando final debería informar yes. Si la interfaz de red está en una zona diferente, abrir el servicio en publicno solucionará las reglas de esa interfaz. La documentación de Cockpit de SUSE utiliza el cockpitservicio firewalld; abrir el servicio especificado es preferible a abrir todo el tráfico o deshabilitar el firewall. También verifique los grupos de seguridad en la nube, los firewalls perimetrales, las políticas de VPN y las ACL de red si la regla del host es correcta pero el cliente sigue agotando el tiempo de espera.

Si su imagen SLES utiliza una configuración de administración de firewall diferente, siga la política de ese sistema en lugar de aplicar comandos de firewalld indiscriminadamente. No borre las reglas del firewall ni lo desactive en un servidor de producción administrado remotamente: esto puede exponer servicios e interrumpir su proceso de administración actual.

4. Distinga un fallo de conexión de un problema de certificado o de inicio de sesión.

Una vez que se carga la página de inicio de sesión, la conexión de red a Cockpit funciona correctamente. Cockpit normalmente espera que las conexiones del navegador utilicen HTTPS y presenta un certificado TLS. Una advertencia sobre un certificado autofirmado o una discrepancia en el nombre no significa que la conexión esté caída. Para un host de laboratorio, verifique la huella digital a través de un canal de confianza antes de aceptar la advertencia. Para sistemas gestionados, instale un certificado cuyo nombre de sujeto coincida con el nombre de host que utilizan los administradores y cuya cadena sea de confianza para sus navegadores.

Si aparece la página de inicio de sesión pero se rechazan las credenciales, verifique el nombre de usuario, la contraseña, el estado de la cuenta y la política de autenticación del servidor. Cockpit generalmente se autentica con las cuentas del sistema; no es una base de datos de usuarios independiente. No incluya contraseñas en comandos ni registros durante la resolución de problemas. Si la página se carga pero la interfaz permanece en blanco o se desconecta después de iniciar sesión, revise la consola del desarrollador del navegador y los registros recientes de Cockpit. Un proxy inverso también puede causar fallos si no admite conexiones WebSocket o reenvía información de protocolo o host incorrecta.

5. Revise los registros y la configuración del proxy cuando las pruebas básicas se hayan completado correctamente.

Captura un breve intervalo de tiempo mientras realizas un nuevo intento de conexión:

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

Busque errores de enlace, permisos o certificados, y mensajes que coincidan con la hora de la prueba. Si el servidor escucha localmente pero un cliente remoto no puede conectarse, investigue la ruta de red y la zona de firewalld antes de modificar la configuración de Cockpit. Si el acceso directo funciona pero el acceso a través de un proxy falla, compare temporalmente mediante una ruta directa permitida y, a continuación, revise la compatibilidad con la actualización de WebSocket del proxy y los encabezados reenviados. Evite modificar la configuración de origen o TLS de Cockpit como primer paso; una configuración incorrecta de la confianza del proxy puede debilitar la seguridad.

Verificar la reparación

Tras realizar un cambio a la vez, verifique los siguientes resultados:

• systemctl status cockpit.socketMuestra que el socket está activo y escuchando.
• El host SLES tiene un proceso escuchando en el puerto esperado, normalmente TCP 9090.
• La regla del firewall está presente en la zona asignada a la interfaz de administración.
• El cliente puede acceder al servidor https://SERVER_IP:9090y ver la página de inicio de sesión de Cockpit.
• Tras la autenticación, la página permanece conectada y el registro reciente no contiene ningún error de inicio o de conexión coincidente.

Si el socket está activo y las comprobaciones locales se realizan correctamente, pero las pruebas TCP remotas siguen agotando el tiempo de espera, es probable que el problema restante se encuentre fuera de Cockpit, como por ejemplo en un cortafuegos, una ruta de red, un registro DNS o una regla VPN. Si el servicio falla en un sistema SLES compatible, guarde el estado de la unidad y la salida del registro, y consulte la documentación de SUSE o el canal de soporte para obtener la configuración exacta del paquete de servicio, en lugar de aplicar correcciones destinadas a otra distribución.

Referencias oficiales

• SUSE: Administración de SUSE Linux Enterprise Server mediante Cockpit
• Proyecto Cockpit: Inicio y activación de sockets de systemd
• Proyecto Cockpit: Puerto y dirección TCP
• Proyecto Cockpit: HTTPS y certificados
• Proyecto Cockpit: Preguntas frecuentes sobre solución de problemas
• SUSE: Configuración del firewall SLES 15 SP5 y zonas firewalld