VPN 너머의 Wake-on-LAN이 안 되나요? 브로드캐스트는 결코 건너가지 않습니다

사무실 기계를 잠들게 하고 집에서 VPN으로 접속해도 기계는 꺼진 채로 있습니다. 터널은 올라가 있고 파일 공유는 응답하며 라우터의 wake-on-LAN 페이지는 요청을 보냈다고 알립니다. 보이는 신호는 모두 네트워크가 정상이라고 말하고, 그래서 이 사례가 혼란스럽습니다: 기계를 깨울 프레임이 기계가 있는 세그먼트에 결코 도달하지 않기 때문입니다.

증상은 터널이 아니라 서브넷을 가리킵니다

잠든 호스트로의 ping은 실패하며 그 부분은 정상입니다. 대기 상태의 기계에는 동작 중인 IP 스택이 없어 ARP나 ICMP에 응답할 수 없고, 어떤 터널 설정으로도 그것은 바뀌지 않습니다. 유용한 시험은 같은 LAN의 두 번째 기계가 깨어나는지, 라우터 자체의 깨우기 페이지가 거기에 연결된 호스트에 대해 동작하는지입니다.

같은 세그먼트에서 시험이 통과하면 문제는 범위에 있습니다. 사용하는 송신자는 VPN 인터페이스에 살고, 그것이 만드는 패킷은 로컬 링크를 위한 브로드캐스트이므로 잘못된 인터페이스로 나가거나 아예 나가지 않습니다. 터널은 고장 난 것이 아니라 잘못된 종류의 트래픽을 나르고 있습니다. 라우터 설정을 하나라도 바꾸기 전에 송신자가 어느 인터페이스를 고르는지 알아내십시오.

magic packet은 프레임이며 서비스가 아닙니다

페이로드는 육 바이트 고정 헤더 0xFF로 시작하고, 이어서 대상 카드의 하드웨어 주소가 열여섯 번 반복되며, 마지막으로 선택적인 네 바이트 SecureOn 암호가 옵니다. 송신자는 보통 이를 UDP로 감싸 포트 7이나 포트 9로 보내지만, 포트 번호는 송신자와 카드 사이의 약속일 뿐 연결할 수 있는 리스너가 아닙니다. 듣고 있는 것도 없고 응답하는 것도 없습니다.

기계를 깨우는 것은 네트워크 인터페이스이며, 시스템의 나머지가 꺼져 있는 동안 대기 전원 레일에서 소량의 회로에 전력을 공급합니다. 그래서 이 설정은 완전한 정전과 잠듦을 모두 견뎌야 합니다: 전원을 끌 때 대기 전원을 끊는 보드에는 아무것도 받을 카드가 남지 않습니다.

라우팅된 터널이 전달하지 못하는 이유

라우팅된 VPN 인터페이스는 두 터널 주소 사이의 점대점 IP 링크입니다. 피어로 향하는 패킷을 나르기 위해 존재하므로 ping과 SSH, 파일 공유가 그 위에서 정상적으로 동작합니다. 브로드캐스트 프레임은 그 피어로 향하지 않으며, 제한 브로드캐스트 주소는 라우터가 당연하게 전달하지 않습니다.

서브넷으로 향하는 브로드캐스트의 전달은 라우터의 의도된 기능이며 대부분의 기본 설정이 꺼 두고, 설령 켜져 있어도 그 서브넷으로 전달될 뿐 특정 잠든 카드로 가지는 않습니다. 잠든 호스트는 ARP에도 응답할 수 없으므로 전달 전에 대상 주소를 해석하려는 라우터는 오지 않을 응답을 기다리다 프레임을 버립니다. 정적 결합 항목이 그 부분을 고치고 브로드캐스트 범위 문제는 그대로 둡니다. 즉 두 개의 별개 제약이고, 하나를 없애도 다른 하나에는 아무 효과가 없습니다.

실제로 카드에 도달하는 세 가지 배치

동작하는 모든 구성은 프레임을 대상의 세그먼트에 두며, 네트워크를 얼마나 어지럽히는지에서 다릅니다:

1. 대상 세그먼트에 항상 켜져 있는 장치를 둡니다. 전원이 유지되는 라우터, NAS 또는 작은 리눅스 상자는 터널로 도달한 순간 프레임을 현지에서 내보낼 수 있고, VPN 쪽은 아무것도 바뀌지 않습니다.
2. 라우터가 직접 프레임을 내보내게 합니다. 많은 펌웨어가 LAN 브리지에서 보내는 깨우기 페이지를 제공하며, 대상이 그 브리지에 있고 두 번째 라우터 뒤에 있지 않다면 동작합니다.
3. 브로드캐스트가 정말 건너가야 한다면 TAP 방식 터널로 두 사이트를 브리지합니다. 그러면 두 브로드캐스트 도메인이 합쳐지고, 브로드캐스트 폭풍과 단일 주소 설계, 두 사이트를 동시에 보는 모든 발견 프로토콜이 따라옵니다.

한 대의 기계라면 첫 번째 선택이 적합합니다. 세 번째는 지속적인 비용이 따르는 네트워크 설계 결정이므로 그렇게 다루어야 하고, 한 대의 데스크톱을 위한 즉석 수정이 아닙니다.

어떤 도우미가 프레임을 내보내고 어느 브리지나 VLAN에 있는지 기록하십시오. 잘못된 인터페이스에서 내보내는 도우미는 완벽한 캡처와 결코 깨어나지 않는 기계를 주며, 그 조합은 반나절을 잡아먹습니다.

클라이언트를 탓하기 전에 전송을 검증하십시오

준비되지 않은 카드는 어떤 송신자도 깨울 수 없으므로 먼저 대상 카드를 확인하십시오. 아래 명령은 지원되는 깨우기 모드와 현재 모드를 읽으며, 현재 값이 g이면 magic packet이 켜져 있다는 뜻입니다:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

전송이 일어나는 동안 도우미에서 캡처를 실행하고, 성공을 가정하지 말고 읽으십시오. 올바른 브리지에서 브로드캐스트 대상 MAC으로 나가는 프레임만이 전송이 동작했다는 증거입니다; 캡처가 비어 있다면 송신자가 다른 인터페이스를 고른 것이고 나머지 시험은 무의미합니다. UDP 데이터그램 대신 원시 프레임을 만드는 송신자는 그 필터에 맞지 않으므로, 아무것도 보내지 않았다고 결론 내리기 전에 도구가 어느 형식을 쓰는지 확인하십시오.

Windows에서는 같은 카드 확인이 powercfg /devicequery wake_armed이며, 시스템을 깨울 수 있는 장치를 나열합니다. 그 목록에 없는 네트워크 어댑터는 케이블 위에서 프레임이 아무리 올바르게 보여도 자신에게 오는 모든 패킷을 무시합니다.

그다음 깨우기 자체와 후속 조치를 확인하십시오. 켜지지만 이름으로 접근할 수 없는 기계에는 고정 주소와 DNS 레코드가 필요합니다: 브로드캐스트를 통한 이름 해석은 여전히 터널을 넘지 못하기 때문입니다. 무선 깨우기는 유선 버전과 별개이며 훨씬 덜 신뢰할 수 있는 기능이므로, VPN을 끌어들이기 전에 같은 세그먼트에서 시험하십시오. 인터페이스 이름과 도우미 호스트를 티켓에 적어 두십시오: 다음 고장도 대개 같은 두 사실에 관한 것이기 때문입니다.