← 글 목록

블로그 서버 접속 불가 문제 분석 보고서

/ 11분 분량
#인프라

2026년 3월 3일, 외부에서 제 블로그 서버에 접속이 불가능한 문제가 발생했습니다. 문제 해결 과정과 그 원인, 그리고 앞으로 유사한 문제를 방지하기 위한 방법을 기록하고자 합니다.

블로그 서버 접속 불가 문제 분석 보고서

2026년 3월 3일, 외부에서 제 블로그 서버에 접속이 불가능한 문제가 발생했습니다. 문제 해결 과정과 그 원인, 그리고 앞으로 유사한 문제를 방지하기 위한 방법을 기록하고자 합니다.

결론부터 정리하면 아래와 같습니다.

블로그 서버 접속 불가 원인: 워커1(94) 노드의 와이파이 연결 실패로 인한 네트워크 단절이 블로그 서비스 중단의 직접적인 원인이었습니다. 공유기 재시작 시 와이파이 재연결에 실패한 것이 발단이었습니다.

호스트네임 오염 원인: 마스터 노드(84)의 IP를 가진 라즈베리파이의 hostname이 SD 카드 이미지 굽기 과정에서 raspiWorker1로 잘못 설정되었고, Cloud-init이 이를 계속해서 덮어쓰면서 발생했습니다. /boot/firmware/user-data 파일의 설정을 수정하여 문제를 해결했습니다.

질문과 탐구

  • 주요 질문:

    • 외부에서 SSH 접속이 왜 안 되는가? (Connection timed out)
    • 폰 데이터로는 접속되는데, 데스크탑에서 접속이 안 되는 이유는 무엇인가?
    • 내부 IP로 접속 시 Connection refused는 무엇을 의미하는가?
    • SSH 서비스 상태는 정상인데 왜 포트 2222로 접속이 안 되는가?
    • 포트포워딩 설정은 정상인데 왜 접속이 안 되는가?
    • 마스터(84)의 호스트네임이 왜 raspiWorker1로 표시되는가?
    • Cloud-init이 hostname 설정을 계속 덮어쓰는 이유는 무엇인가?

  • 탐구 과정:

    1. SSH 접속 시 Connection timed out 오류 발생 원인을 파악하기 위해 폰 데이터, 데스크탑 네트워크 환경별 접속 시도를 진행했습니다.
    2. 내부 IP 접속 시 Connection refused 오류를 통해 SSH 서비스 자체의 문제인지, 아니면 포트포워딩의 문제인지 구분하려 했습니다.
    3. systemctl status ssh 및 ss -tlnp 명령어를 통해 SSH 서비스와 포트 상태를 확인했습니다.
    4. 공유기의 포트포워딩 설정을 점검하고, IP 주소 할당 및 포워딩 대상 IP를 대조했습니다.
    5. 워커1(94)의 네트워크 연결 상태를 확인하고, 물리적 재시작을 통해 문제를 해결했습니다.
    6. 이후 발견된 마스터(84)의 호스트네임 문제를 해결하기 위해 hostnamectl, /etc/hosts, /etc/hostname 등 다양한 설정 파일을 수정했습니다.
    7. Cloud-init이 hostname 설정을 지속적으로 덮어쓰는 원인을 파악하기 위해 /etc/cloud/cloud.cfg, /boot/firmware/user-data 등 관련 설정 파일들을 깊이 탐구했습니다.

핵심 학습 내용

  • 배운 주요 개념:

    • 네트워크 접속 문제 해결 단계: 외부 접속 → 내부 IP 접속 → 서비스 상태 확인 → 포트 확인 → 설정 점검 순서로 체계적인 접근의 중요성을 배웠습니다.
    • SSH 접속 오류: Connection timed out은 네트워크 도달 불가, Connection refused는 서버에서 요청 거부를 의미함을 이해했습니다.
    • 포트포워딩: 외부에서 내부 IP로 접속할 때 공유기의 포트포워딩 설정이 어떻게 동작하는지, 그리고 내부 IP로 직접 접속 시에는 이 과정이 생략됨을 알게 되었습니다.
    • Cloud-init: 라즈베리파이 우분투 이미지에 포함된 Cloud-init이 초기 설정을 어떻게 관리하며, 특히 /boot/firmware/user-data 파일이 hostname 및 기타 설정을 영구적으로 적용하는 데 핵심적인 역할을 한다는 것을 알게 되었습니다.
    • SD 카드 이미지 굽기: Raspberry Pi Imager와 같은 도구를 사용할 때 "고급 설정"에서 hostname, SSH 키 등을 명확히 설정해야 한다는 점을 배웠습니다.

  • 중요한 포인트 정리:

    • 네트워크 문제 발생 시, 외부 접속뿐만 아니라 내부 IP 접속, 그리고 해당 서비스의 상태를 단계적으로 확인하는 것이 중요합니다.
    • Connection timed out과 Connection refused 오류는 원인이 다르므로, 이를 구분하여 문제 해결의 방향을 설정해야 합니다.
    • Cloud-init은 특정 설정 파일을 통해 초기 환경을 구성하며, 이 설정이 재부팅 시에도 유지될 수 있음을 인지해야 합니다. 특히 /boot/firmware/user-data 파일의 역할이 중요했습니다.

  • 예시 코드 (문제 해결 과정 중 사용):

    • SSH 서비스 상태 확인:

      sudo systemctl status ssh

    • 포트 확인:

      sudo ss -tlnp | grep 2222

    • 호스트네임 변경 시도 (초기):

      sudo hostnamectl set-hostname raspiMaster

    • Cloud-init 설정 확인 (문제 원인 파악):

      cat /boot/firmware/user-data

    • Cloud-init 설정 수정 (최종 해결):

      sudo sed -i 's/hostname: raspiWorker1/hostname: raspiMaster/' /boot/firmware/user-data
sudo sed -i 's/manage_etc_hosts: true/manage_etc_hosts: false/' /boot/firmware/user-data

이해한 내용

  • 새로 알게 된 것:

    • 라즈베리파이 우분투 이미지에 기본 포함된 Cloud-init의 작동 방식과 /boot/firmware/user-data 파일의 역할에 대해 깊이 이해했습니다. 이 파일이 SD 카드 이미지 굽기 단계에서 hostname, 사용자 설정 등을 정의하고, 매 부팅 시 이 설정을 적용한다는 것을 알게 되었습니다.
    • IP 주소 할당(DHCP)으로 인해 내부 IP가 변경될 수 있으며, 이를 고정하기 위한 방법(MAC 주소 기반 고정 IP 할당)에 대해 알게 되었습니다.

  • 개념 정리:

    • 블로그 서버 접속 불가 원인: 워커1(94) 노드의 와이파이 연결 실패로 인한 네트워크 단절이 블로그 서비스 중단의 직접적인 원인이었습니다. 공유기 재시작 시 와이파이 재연결에 실패한 것이 발단이었습니다.
    • 호스트네임 오염 원인: 마스터 노드(84)의 IP를 가진 라즈베리파이의 hostname이 SD 카드 이미지 굽기 과정에서 raspiWorker1로 잘못 설정되었고, Cloud-init이 이를 계속해서 덮어쓰면서 발생했습니다. /boot/firmware/user-data 파일의 설정을 수정하여 문제를 해결했습니다.

실전 적용

  • 이 지식을 어디에 적용할 수 있을지:

    • 개인 서버, NAS, IoT 장치 등 네트워크 연결이 중요한 환경에서 발생하는 접속 문제를 진단하고 해결하는 데 적용할 수 있습니다.
    • 다수의 라즈베리파이나 서버를 운영할 때, hostname 및 네트워크 설정 충돌 문제를 예방하고 관리하는 데 활용할 수 있습니다.
    • Cloud-init과 같은 초기 설정 자동화 도구의 작동 방식을 이해하고, 커스터마이징하는 데 도움이 됩니다.

  • 실습 계획:

    • 새로운 SD 카드에 라즈베리파이 OS를 설치할 때, Raspberry Pi Imager의 고급 설정을 활용하여 hostname, 사용자, SSH 키 등을 명확하게 지정하고, user-data 파일을 확인하는 실습을 진행하겠습니다.
    • 여러 대의 라즈베리파이를 구성할 때, 각 노드의 hostname과 IP 주소를 명확히 관리하는 방안을 구축하겠습니다.

  • 응용 아이디어:

    • Cloud-init 설정 파일을 자동화하여 여러 대의 라즈베리파이를 일괄적으로 구성하는 스크립트를 만들어 볼 수 있습니다.
    • 네트워크 장비(공유기)의 펌웨어 업데이트 시점을 파악하고, 해당 시간에 맞춰 서버 노드들의 네트워크 상태를 미리 점검하는 루틴을 마련할 수 있습니다.

추가 학습 계획

  • 더 깊이 공부하고 싶은 부분:

    • Watchdog 타이머: 네트워크 연결이 끊겼을 때 자동으로 서버를 재시작하여 서비스 가용성을 높이는 watchdog 설정에 대해 더 깊이 공부하고 싶습니다.
    • 네트워크 모니터링 도구: UptimeRobot 외에, Prometheus, Grafana 등 좀 더 전문적인 모니터링 도구를 활용하여 서버 상태를 상시 감시하는 방법을 익히고 싶습니다.
    • Cloud-init 고급 설정: user-data 파일을 통해 패키지 설치, 서비스 설정 등을 자동화하는 고급 기능을 학습하고 싶습니다.

  • 관련 자료 찾기:

    • Raspberry Pi 공식 문서 (Cloud-init, 네트워크 설정 관련)
    • Ubuntu Server 공식 문서 (Netplan, Cloud-init 관련)
    • Watchdog 하드웨어 및 소프트웨어 설정 가이드

  • 다음 학습 주제:

    • Docker를 활용한 블로그 서버 컨테이너화 및 관리
    • Nginx를 이용한 웹 서버 설정 및 로드 밸런싱

이번 문제해결 과정에서 접한 파일, 커맨드들

  • 언급된 참고 자료:
    • sudo systemctl status ssh
    • sudo ss -tlnp | grep 2222
    • sudo hostnamectl set-hostname raspiMaster
    • /etc/hosts
    • /etc/hostname
    • /etc/cloud/cloud.cfg
    • /etc/cloud/cloud.cfg.d/
    • /boot/firmware/user-data

이번 경험을 통해 문제 해결 능력뿐만 아니라, 시스템의 깊은 곳까지 이해하는 것이 얼마나 중요한지 다시 한번 느꼈습니다. 이러한 기록이 다른 학습자들에게도 도움이 되기를 바랍니다.