Rocky Linux 8.10 기반 서비스 업데이트 실패 원인 분석 및 문제 해결 가이드

1. 개요 및 현상 요약

• 시스템 환경: Rocky Linux 8.10
• 장애 현상: 특정 솔루션의 서비스 업데이트 수행 시 Fail 메시지 출력 및 진행 불가.
• 기본 점검 데이터:
  • nslookup [도메인] 정상 -> DNS 서버 정상 작동 확인.
  • ping [IP] 정상 -> L3 레이어(ICMP) 연결성 및 회선 정상 확인.
• 종합 가설: 하위 네트워크(L3/L4)는 정상이나, L7 애플리케이션 레이어(HTTPS/443)에서 사내 보안 장비(방화벽/유해사이트 차단)의 트래픽 차단 또는 Rocky Linux 8의 보안 정책(Crypto Policies) 충돌로 인해 SSL/TLS Handshake 단계에서 세션이 강제 종료되는 상태로 추정됨.

---

2. 발생 가능한 핵심 원인 분석 (Root Causes)

① 사내 인프라 보안 장비(차세대 방화벽/DPI)의 패킷 차단

• 원인: 443 포트 자체는 열려 있으나, 방화벽의 Deep Packet Inspection(DPI) 또는 Application Control 기능이 업데이트 트래픽의 페이로드를 비정상/우회 트래픽으로 오인하여 강제로 TCP Reset(RST) 패킷을 찔러 넣어 연결을 끊는 경우입니다.

② 유해사이트 차단 솔루션의 URL 평판 기반 블로킹

• 원인: 차단 솔루션(예: WebKeeper 등)이 업데이트 서버 도메인을 유해하거나 검증되지 않은 사이트로 분류하여 차단 페이지(HTML)로 강제 리다이렉트시키는 경우입니다. 이 과정에서 SSL 인증서 불일치가 일어나 핸드쉐이크 에러가 발생합니다.

③ Rocky Linux 8.10 시스템 암호화 정책(Crypto Policies) 충돌

• 원인: Rocky Linux 8의 기본 보안 정책(DEFAULT)은 TLS 1.0/1.1, SHA-1 등 취약한 알고리즘을 거부합니다. 솔루션사의 업데이트 서버가 구형 프로토콜이나 Cipher Suite를 고집할 경우 OS가 먼저 연결을 거부합니다.

④ SSL 인스펙션(복호화) 장비의 사설 인증서 주입

• 원인: 사내 복호화 장비가 트래픽 감시를 위해 중간에서 가짜 인증서를 주입(MITM)했으나, Rocky Linux 시스템 종단에서 이를 신뢰할 수 없는 인증서(Unknown CA)로 판단하여 세션을 드롭하는 경우입니다.

⑤ 시스템 시간 동기화(NTP) 오류

• 원인: Rocky Linux 서버의 시스템 시간이 실제 시간과 너무 많이 어긋나, 업데이트 서버 인증서의 유효 기간 범위를 벗어나 핸드쉐이크가 실패하는 경우입니다.

---

3. 엔지니어링 마스터 트러블슈팅 플로우차트

                 [시작: 솔루션 업데이트 Fail]
                               │
                               ▼
                    [nslookup / ping 점검]
                               │
               ├───────────────────────────────┐
           (실패)                           (성공)
               │                               │
               ▼                               ▼
     [DNS/네트워크 회선 복구]          [curl -Iv [업데이트서버URL] 수행]
                                               │
       ┌───────────────────────────────────────┴───────────────────────────────────────┐
       ▼                                       ▼                                       ▼
 [Case 1: HTTP 응답 코드 수신]      [Case 2: Unknown CA / Alert]          [Case 3: Handshake / Connection Reset]
       │                                       │                                       │
       ▼                                       ▼                                       ▼
[curl http://[URL] (80) 테스트]    [openssl s_client로 Issuer 확인]         [Crypto Policies 임시 완화 테스트]
       │                                       │                                       │
       ├───────────────────┐                   ├───────────────────┐                   ├───────────────────┐
  (차단 화면 수신)     (정상 응답)         (사내 보안장비명)     (공인 CA 명)          (업데이트 성공)     (업데이트 실패)
       │                   │                   │                   │                   │                   │
       ▼                   ▼                   ▼                   ▼                   ▼                   ▼
 [유해사이트차단]     [포트 오포워딩]     [SSL 인스펙션 간섭]   [서버 시간 확인]      [구형 암호화 규격]   [방화벽 DPI 차단/
  (White-list요청)   (인프라팀 확인)      (SSL Bypass 요청)   (chrony 동기화)      (LEGACY 유지/원복)   TCP Reset 덤프분석]

---

4. 원인 파악 및 기술적 증명 방법 (Proof of Concept)

엔지니어는 감이 아닌 데이터로 증명해야 합니다. 아래 명령어들로 원인을 확정합니다.

검증 1: 차단 솔루션의 리다이렉션 유무 확인 (Case 1 증명)

Bash

curl -L -v http://[업데이트서버_도메인]

• 엔지니어 판단: 포트 80(HTTP)으로 요청했을 때, 정상적인 API 응답이 아니라 사내 보안 시스템의 안내 문구나 Access Denied 같은 HTML 코드가 리턴된다면 유해사이트 차단 솔루션의 간섭이 100% 확정됩니다.

검증 2: 인증서 발급자(Issuer) 추적 (Case 2 증명)

Bash

openssl s_client -connect [업데이트서버_도메인]:443 -showcerts

• 엔지니어 판단: 출력 결과 중 issuer= 뒤에 오는 기관명을 확인합니다. Let's Encrypt나 DigiCert 등이 아닌 사내 방화벽 장비명(예: Fortinet, PaloAlto) 또는 회사 내부 CA 이름이 적혀 있다면 SSL 인스펙션 장비가 트래픽을 가로채 변조하고 있음을 증명합니다.

검증 3: OS 보안 규격 호환성 확인 (Case 3 증명)

Bash

sudo update-crypto-policies --set LEGACY
# 이후 업데이트 재시도

• 엔지니어 판단: 정책을 LEGACY로 낮춘 후 업데이트가 정상 진행된다면, OS의 최신 암호화 정책이 업데이트 서버의 노후화된 암호화 스위트(TLS 1.0 등)를 차단한 것입니다. (확인 후 sudo update-crypto-policies --set DEFAULT로 원복 필수)

검증 4: 패킷 캡처를 통한 TCP Reset(RST) 주입 증명

Bash

sudo tcpdump -nnvv -i any host [업데이트서버_IP] and tcp

• 엔지니어 판단: Wireshark로 열었을 때 Client Hello 직후 외부 서버가 아닌 비정상적인 TTL 값을 가진 RST 패킷이 들어와 세션이 찢어진다면, 방화벽의 DPI(Deep Packet Inspection) 차단 기능이 작동한 것입니다.

---

5. 단계별 종합 조치 가이드

가이드 A: 방화벽 및 유해사이트 차단 솔루션 예외 처리 (인프라 협조)

• 조치 내용: 증명된 tcpdump 및 차단 화면 캡처본을 첨부하여 사내 보안/인프라 팀에 티켓을 요청합니다.
• 요청 항목: "해당 Rocky Linux 서버 IP ➡️ 업데이트 서버 목적지 IP/도메인"에 대해 방화벽 오픈, 유해사이트 카테고리 예외 등록(White-list)을 진행합니다.

가이드 B: SSL 인스펙션 장비 대상 제외 (SSL Bypass)

• 조치 내용: 보안 장비가 암호화 패킷을 복호화하지 않도록 보안 담당자에게 업데이트 서버 도메인을 SSL Bypass 목록에 등록해 달라고 요청합니다.
• 우회 조치: 사정상 Bypass가 불가능하다면, 방화벽 장비의 자체 Root CA 인증서(.crt)를 전달받아 Rocky Linux 시스템에 수동 등록하여 장비를 신뢰하게 만듭니다.
• Bash
• sudo cp firewall_root_ca.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust

가이드 C: 업데이트 서버의 구형 보안 암호화 대응

• 조치 내용: 솔루션 개발사 측에 업데이트 서버의 SSL/TLS 스펙(TLS 1.2 이상 사용 권장) 상향을 공식 요구합니다.
• 임시 조치: 당장 업데이트를 받아야 한다면 아래 명령어로 특정 알고리즘(SHA-1 등)만 임시 허용하여 패치 후 다시 원복합니다.

Bash

    sudo update-crypto-policies --set LEGACY
    # (업데이트 수행)
    sudo update-crypto-policies --set DEFAULT

---

6. 결론 및 종합 제언

본 장애는 단순한 회선 단절(L3/L4)이 아니라, **L7 애플리케이션 레이어 및 인프라 보안 정책이 복합적으로 얽힌 트러블슈팅 케이스**입니다.

엔지니어는 제시된 플로우차트에 따라 `curl` 검증과 `openssl` 도구를 활용해 보안 장비의 개입(Case 1, 2)인지, OS 내부 정책 문제(Case 3)인지를 명확한 로그 데이터로 구분해야 합니다. 이후 도출된 객관적 증거(인증서 발급자 변조 확인, 차단 HTML 바디 등)를 기반으로 사내 보안 팀이나 솔루션 개발사와 협의하여 예외 처리 정책을 반영하는 것이 본 문제를 가장 빠르고 정확하게 해결하는 프로세스입니다.