SUSE Linux Enterprise Server에서 Cockpit 웹 콘솔이 연결되지 않는 문제 해결

Cockpit 웹 콘솔이 SUSE Linux Enterprise Server(SLES) 호스트에 연결되지 않으면 먼저 연결을 시도한 https://SERVER_IP:9090다음, 해당 서비스가 cockpit.socket수신 대기 중인지, 그리고 방화벽에서 서버의 네트워크 인터페이스에서 사용하는 영역에서 Cockpit 서비스가 허용되는지 확인하십시오. 일반적인 설치 환경에서는 이러한 확인을 통해 잘못된 URL 또는 포트, 비활성화된 소켓, 누락된 Cockpit 패키지 또는 차단된 수신 연결과 같은 가장 일반적인 원인을 해결할 수 있습니다.

이 가이드는 systemd를 사용하고 구성된 제품 저장소에서 Cockpit을 ​​사용할 수 있는 SLES 시스템에 적용됩니다. SUSE의 최신 SLES 16 Cockpit 가이드에는 아래의 패턴 설치 및 소켓 활성화 명령이 설명되어 있습니다. 패키지 가용성 및 이름은 SLES 서비스 팩, 모듈 및 지원 권한에 따라 다를 수 있으므로, 이전 버전의 SLES 15 호스트에서는 설치 오류를 서비스 오류로 간주하기 전에 활성화된 SUSE 저장소에서 Cockpit이 제공되는지 확인하십시오.

증상부터 시작하세요

브라우저에 표시되는 오류를 사용하여 원인을 좁히세요. 시간 초과 또는 "사이트에 연결할 수 없습니다" 오류는 일반적으로 라우팅, 방화벽 규칙 또는 활성화되지 않은 리스너와 관련이 있습니다. 연결 거부는 선택한 주소와 포트에서 연결을 수락하는 서비스가 없음을 의미합니다. Cockpit 로그인 페이지가 표시되면 웹 서비스에 연결할 수 있다는 뜻이며, 이후 인증 오류가 발생하는 것은 다른 계정 또는 정책 문제일 수 있습니다. 인증서 경고는 HTTPS 협상이 서버에 도달했지만 브라우저가 인증서 또는 인증서 이름을 신뢰하지 않음을 의미합니다.

예를 들어, 관리자가 주소가 인 서버에 접속할 수 없다고 가정해 보겠습니다 192.0.2.25. https://192.0.2.25:9090관리 권한이 있는 컴퓨터에서 테스트해 보세요. Cockpit은 일반적으로 9090번 포트에서 HTTPS를 사용합니다. IP 주소만 입력하면 다른 서비스가 열릴 수 있고, 를 사용하면 http://예상되는 로그인 화면 대신 리디렉션되거나 브라우저 경고가 표시될 수 있습니다.

1. URL 및 접속 가능성을 확인하세요

SLES 콘솔 또는 신뢰할 수 있는 인벤토리에서 서버의 현재 주소를 확인하고 포트 번호를 명시적으로 포함하십시오.

https://192.0.2.25:9090

클라이언트 측에서 TCP 포트 9090에 접근 가능한지 테스트합니다. netcat이 설치된 Linux 관리 워크스테이션에서 다음 명령을 실행합니다.

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이 설치되지 않았을 수 있습니다. Cockpit 패턴을 제공하는 저장소가 활성화된 SLES 릴리스의 경우, 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. 활성 방화벽 영역에서 Cockpit을 ​​허용합니다.

호스트 방화벽이 연결을 끊으면 활성 리스너도 접근할 수 없을 수 있습니다. 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 설명서에서는 cockpitfirewalld 서비스를 사용하므로, 모든 트래픽을 허용하거나 방화벽을 비활성화하는 것보다 지정된 서비스를 여는 것이 좋습니다. 호스트 규칙이 올바르지만 클라이언트가 여전히 시간 초과되는 경우 클라우드 보안 그룹, 경계 방화벽, 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

바인딩 오류, 권한 또는 인증서 오류, 그리고 테스트 시간과 일치하는 메시지를 확인하십시오. 서버가 로컬에서 수신 대기하지만 원격 클라이언트가 연결할 수 없는 경우, Cockpit 구성을 변경하기 전에 네트워크 경로와 firewalld 영역을 조사하십시오. 직접 액세스는 되지만 프록시를 통한 액세스가 실패하는 경우, 허용된 직접 경로를 통해 임시로 비교한 다음 프록시의 WebSocket 업그레이드 지원 및 전달 헤더를 검토하십시오. 첫 단계로 Cockpit의 원본 또는 TLS 설정을 변경하지 마십시오. 잘못된 프록시 신뢰 설정은 보안을 약화시킬 수 있습니다.

수리를 확인하십시오

한 번에 한 가지씩 변경한 후, 다음 결과를 확인하십시오.

• systemctl status cockpit.socket소켓이 활성화되어 수신 대기 중임을 보여줍니다.
• SLES 호스트는 예상되는 포트(일반적으로 TCP 9090)에서 수신 대기합니다.
• 방화벽 규칙은 관리 인터페이스에 할당된 영역에 있습니다.
• 클라이언트는 해당 주소로 서버에 접속하여 https://SERVER_IP:9090Cockpit 로그인 페이지를 볼 수 있습니다.
• 인증 후 페이지 연결 상태는 유지되며 최근 로그에는 시작 오류 또는 연결 오류가 기록되지 않았습니다.

소켓이 활성화되어 있고 로컬 검사가 성공했지만 원격 TCP 테스트에서 여전히 시간 초과가 발생하는 경우, 나머지 오류는 상위 방화벽, 네트워크 경로, DNS 레코드 또는 VPN 규칙과 같은 Cockpit 자체 외부의 문제일 가능성이 높습니다. 지원되는 SLES 시스템에서 서비스가 실패하는 경우, 장치 상태 및 저널 출력을 저장하고 다른 배포판용으로 작성된 수정 사항을 적용하는 대신 SUSE 설명서 또는 지원 채널에서 정확한 서비스 팩 구성을 확인하십시오.

공식 참고 자료

• SUSE: Cockpit을 ​​이용한 SUSE Linux Enterprise Server 관리
• 콕핏 프로젝트: 시작 및 systemd 소켓 활성화
• 콕핏 프로젝트: TCP 포트 및 주소
• 콕핏 프로젝트: HTTPS 및 인증서
• 콕핏 프로젝트: 문제 해결 FAQ
• SUSE: SLES 15 SP5 방화벽 구성 및 firewalld 영역