Исправлена ​​ошибка подключения веб-консоли Cockpit на сервере SUSE Linux Enterprise Server.

Если веб-консоль Cockpit не подключается к хосту SUSE Linux Enterprise Server (SLES), сначала попробуйте подключиться через https://SERVER_IP:9090, затем убедитесь, что cockpit.socketпрослушивает и что брандмауэр разрешает службу Cockpit в зоне, используемой сетевым интерфейсом сервера. При стандартной установке эти проверки устраняют наиболее распространенные причины: неправильный URL-адрес или порт, неактивный сокет, отсутствующие пакеты Cockpit или заблокированное входящее соединение.

Данное руководство относится к системам SLES, использующим systemd и имеющим Cockpit в настроенных репозиториях продуктов. В текущем руководстве SUSE по Cockpit для SLES 16 описаны команды установки шаблона и активации сокета, приведенные ниже. Доступность и названия пакетов могут различаться в зависимости от пакета обновлений SLES, модуля и прав на поддержку, поэтому на более старых хостах SLES 15 убедитесь, что Cockpit предлагается в включенных репозиториях SUSE, прежде чем рассматривать ошибку установки как ошибку обслуживания.

Начните с симптома.

Используйте сообщение об ошибке в браузере, чтобы сузить круг поиска причины. Ошибка тайм-аута или «сайт недоступен» обычно указывает на проблемы с маршрутизацией, правилами брандмауэра или неактивным прослушивателем. Отказ в соединении часто означает, что ничто не принимает соединения по выбранному адресу и порту. Страница входа в Cockpit означает, что веб-сервис доступен; более поздняя ошибка аутентификации указывает на отдельную проблему с учетной записью или политикой. Предупреждение о сертификате означает, что согласование HTTPS достигло сервера, но браузер не доверяет сертификату или его имени.

Например, предположим, что администратор не может открыть сервер, адрес которого — 192.0.2.25. Проверьте это https://192.0.2.25:9090с машины, которой должен быть разрешен доступ к администрированию. Cockpit обычно использует HTTPS на порту 9090. Ввод только IP-адреса может открыть другую службу, а использование http://может привести к перенаправлению или предупреждению браузера вместо ожидаемого экрана входа в систему.

1. Проверьте URL-адрес и доступность.

Подтвердите текущий адрес сервера в консоли SLES или в доверенном списке серверов и явно укажите порт:

https://192.0.2.25:9090

На клиентской стороне проверьте доступность TCP-порта 9090. На рабочей станции администратора Linux с установленным netcat выполните следующую команду:

nc -vz 192.0.2.25 9090

Успешное TCP-соединение доказывает лишь доступность порта; оно не гарантирует работоспособность входа в систему. Таймаут указывает на необходимость проверки активной зоны брандмауэра сервера, любого вышестоящего сетевого брандмауэра, маршрутизации и доступа к VPN. Отказ указывает на необходимость проверки прослушивателя на хосте SLES. Если netcat недоступен, проверьте соединение через браузер или используйте другой одобренный инструмент для проверки TCP-соединения, вместо установки неодобренной утилиты на рабочем хосте.

2. Убедитесь, что Cockpit установлен и его разъем активен.

Подключитесь через SSH или локальную консоль и проверьте сокет. Cockpit обычно использует активацию сокета systemd: systemd прослушивает входящие соединения от имени Cockpit и запускает веб-сервис по запросу. Поэтому ключевым модулем для проверки обычно является cockpit.socket, а не постоянно работающий cockpit.service.

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

Найдите активный/слушающий сокет и слушатель, привязанный к порту 9090. Если устройство отсутствует, Cockpit может быть не установлен. В версиях SLES, в репозиториях которых включен шаблон Cockpit, SUSE описывает установку следующим образом:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Если Zypper сообщает, что шаблон не найден, проверьте продукт, пакет обновлений, включенные модули, состояние репозитория и права на поддержку у своего администратора SUSE. Не добавляйте сторонний репозиторий, не имеющий отношения к делу, только для того, чтобы команда выполнилась успешно. После подтверждения установки Cockpit включите и запустите его сокет:

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

Эта --nowопция запускает сокет немедленно и активирует его при последующих загрузках. Если systemd сообщает о сбое модуля, проверьте точное сообщение об ошибке, прежде чем многократно перезапускать его:

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

3. Разрешите доступ к кабине пилота через активную зону межсетевого экрана.

Активный слушатель может оставаться недоступным, если межсетевой экран хоста разрывает соединение. В текущих версиях SLES использует firewalld для управления межсетевым экраном. Сначала определите активную зону и назначенный ей интерфейс:

sudo firewall-cmd --get-active-zones

Затем добавьте указанную службу Cockpit в зону, содержащую интерфейс управления. Замените publicна фактическую зону, указанную на вашем хосте:

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

Итоговая команда должна вывести сообщение об ошибке yes. Если сетевой интерфейс находится в другой зоне, открытие службы в этой зоне publicне исправит правила для данного интерфейса. В документации SUSE Cockpit используется cockpitслужба firewalld; открытие указанной службы предпочтительнее, чем открытие всего трафика или отключение брандмауэра. Также проверьте группы безопасности облака, периметровые брандмауэры, политики VPN и сетевые списки контроля доступа (ACL), если правило хоста корректно, но клиент по-прежнему выдает ошибку тайм-аута.

Если в вашем образе SLES используется другая конфигурация управления брандмауэром, следуйте политике этой системы, а не применяйте команды firewalld вслепую. Не очищайте правила брандмауэра и не отключайте брандмауэр на удаленно администрируемом производственном сервере: это может привести к открытию доступа к службам и нарушить текущий способ управления.

4. Разделите сбой подключения от проблем с сертификатом или входом в систему.

После загрузки страницы входа в систему сетевой путь к Cockpit работает. Cockpit обычно ожидает, что браузерные соединения будут использовать HTTPS, и предоставляет TLS-сертификат. Предупреждение о самоподписанном сертификате или несоответствии имени не означает, что сокет недоступен. Для лабораторного хоста проверьте отпечаток сертификата через доверенный канал, прежде чем принимать предупреждение. Для управляемых систем установите сертификат, имя субъекта которого совпадает с именем хоста, используемым администраторами, и цепочка сертификатов которого является доверенной для их браузеров.

Если страница входа отображается, но учетные данные отклоняются, проверьте имя пользователя, пароль, состояние учетной записи и политику аутентификации сервера. Cockpit обычно аутентифицируется с помощью системных учетных записей; это не отдельная база данных пользователей. Не указывайте пароли в командах или журналах во время устранения неполадок. Если страница загружается, но интерфейс остается пустым или отключается после входа в систему, проверьте консоль разработчика браузера и последние журналы Cockpit. Обратный прокси-сервер также может вызывать сбои, если он не поддерживает соединения WebSocket или пересылает неверный протокол или информацию о хосте.

5. После проверки основных параметров проверьте журналы и настройки прокси-сервера.

Сделайте снимок небольшого фрагмента лога во время первой попытки подключения:

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

Проверьте наличие ошибок привязки, ошибок разрешений или сертификатов, а также сообщений, совпадающих со временем тестирования. Если сервер прослушивает локально, но удаленный клиент не может подключиться, проверьте сетевой путь и зону firewalld, прежде чем изменять конфигурацию Cockpit. Если прямой доступ работает, но доступ через прокси-сервер не работает, временно сравните его с разрешенным прямым маршрутом, затем проверьте поддержку обновления WebSocket и пересылаемые заголовки прокси-сервера. Избегайте изменения настроек источника или TLS в Cockpit на первом этапе; неправильные настройки доверия к прокси-серверу могут ослабить безопасность.

Проверьте ремонт.

Внося изменения по одному, проверьте следующие результаты:

• systemctl status cockpit.socketОтображает, что сокет активен и находится в режиме прослушивания.
• На хосте SLES установлен слушатель на ожидаемом порту, обычно TCP 9090.
• Правило брандмауэра присутствует в зоне, назначенной интерфейсу управления.
• Клиент может подключиться к серверу по адресу https://SERVER_IP:9090и увидеть страницу входа в Cockpit.
• После аутентификации страница остается подключенной, и в последних записях журнала отсутствуют соответствующие ошибки запуска или подключения.

Если сокет активен и локальные проверки проходят успешно, но удаленные TCP-тесты по-прежнему завершаются по таймауту, оставшаяся неисправность, вероятно, находится вне самого Cockpit, например, в брандмауэре вышестоящего сервера, сетевом маршруте, DNS-записи или правиле VPN. Если служба не работает в поддерживаемой системе SLES, сохраните состояние модуля и вывод журнала и проверьте документацию SUSE или канал поддержки для получения точной конфигурации пакета обновлений, вместо того чтобы применять исправления, предназначенные для другого дистрибутива.

Официальные ссылки

• SUSE: Администрирование SUSE Linux Enterprise Server с помощью Cockpit
• Проект Cockpit: запуск и активация сокета systemd.
• Проект «Кабина пилота»: TCP-порт и адрес
• Проект Cockpit: HTTPS и сертификаты
• Проект «Кабина пилота»: Часто задаваемые вопросы по устранению неполадок
• SUSE: Настройка брандмауэра и зон firewalld в SLES 15 SP5