WOL 장애 조치 및 네트워크 분석 보고서 (실험결과 포함)

2대의 서버간 패킷을 전달하는 트럭 이미지

1. 개요 (Background)

  • 발신측: Raspberry Pi 5 (192.168.0.xxx)
  • 수신측: RTX 2060 PC (MAC: AB:CD:EF:GH:IJ:KL, IP: 192.168.0.xxx)
  • 네트워크 구성 변화:
  • 기존(정상): Raspi와 2060 PC가 동일한 공유기(브릿지B) 하단에 연결 (물리적 동일 구역)
  • 변경(문제): 2060 PC를 브릿지B의 상위 공유기(A) 직결로 이동 (물리적 구역 분리)
  • 증상: 기존에 사용하던 기본 WOL 명령(255.255.255.255)으로 PC 전원이 켜지지 않음.

2. 장애 현상 (Symptoms)

  • 실패 케이스: wakeonlan [MAC] (Limited Broadcast)
  • 송신 대상: 255.255.255.255:9
  • 결과: 2060 PC 반응 없음.
  • 성공 케이스: wakeonlan -i 192.168.0.255 [MAC] (Directed Broadcast)
  • 송신 대상: 192.168.0.255:9
  • 결과: 2060 PC 전원 켜짐 성공.

3. 실험 및 검증 (Experiments)

✅ 실험 1: 발신측(Raspi) 패킷 송출 여부 확인

  • 목적: OS 또는 소프트웨어 레벨의 송신 오류 가능성 배제.
  • 방법: tcpdump를 이용한 인터페이스 모니터링.
# Raspi 터미널
$ sudo tcpdump -ni eth0 udp port 9
19:25:35.861285 IP 192.168.0.xxx.52072 > 255.255.255.255.9: UDP, length 102
  • 결론: Raspi는 패킷을 정상적으로 생성하여 네트워크로 던지고 있음 확인.

✅ 실험 2: 수신측(2060 PC) 패킷 도달 여부 확인

  • 목적: 네트워크 장비(TP-Link 브릿지)의 브로드캐스트 차단 여부 확인.
  • 방법: 2060 PC에서 tcpdump 실행 후 Raspi에서 기본 명령 발송.
# 2060 PC 터미널 (수신 대기)
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
# (결과: 아무런 패킷도 캡처되지 않음)
  • 결론: 255.255.255.255 패킷은 브릿지B 구간을 통과하지 못함.

4. 기술적 원인 (Root Cause)

image 본 문제는 브로드캐스트의 스코프(Scope)와 브릿지 장비의 패킷 포워딩 정책 차이로 인해 발생함.

구분 Limited Broadcast (255.255.255.255) Directed Broadcast (192.168.0.255)
의미 "내가 속한 이 물리적 선(Link) 끝까지만" "이 IP 대역을 쓰는 네트워크 전체"
브릿지 동작 로컬 트래픽으로 간주하여 상위 노드로 넘기지 않음. 유효한 네트워크 주소를 가진 트래픽으로 간주하여 전달.
WOL 결과 도달 실패 (네트워크 경계에서 차단됨) 도달 성공 (상위노드인 공유기A를 거쳐 2060 PC 도달)

5. 조치 결과 (Resolution)

  • 해결 방법: -i 192.168.0.255 옵션을 통해 서브넷 브로드캐스트 주소를 명시.
  • 최종 적용: .bashrc에 전용 alias 등록으로 편의성 확보.
alias wake2060='wakeonlan -i 192.168.0.255 ab:cd:ef:gh:ij:kl'

💡 최종 통찰 (Insight)

255.255.255.255는 보기와는 다르게 Local 혹은 Limited Broadcast의 성격을 가지고 있어서 물리적 연결 한계를 벗어날 수 없다.

따라서 네트워크가 물리적으로 분리된 환경(공유기 하위 브릿지 등)에서 패킷을 뿌릴 때는 "특정 동네를 지정한 타겟 방송(192...255)"이 훨씬 효율적이고 확실한 전달력을 가짐을 확인하였다.