VPN으로 잠든 집 PC 깨우기: 패킷은 어디서 오는가

연결하면 라우터가 응답하고 데스크톱은 어두운 채로 남습니다. 터널은 정상입니다; 기계를 깨웠을 패킷은 기계가 수신 대기하는 세그먼트에 끝내 도달하지 못했습니다. 라우터에서 거꾸로 경로를 따라가면 그것이 어디서 죽는지 보입니다.

세 기기가 세 가지 일을 합니다. 이것들을 뒤섞는 것이 깨우기 시도가 영원히 도는 흔한 이유입니다.

원격 클라이언트에서 시작해 경로를 따라가세요

호텔 네트워크에서, 그림에서 유일하게 항상 켜져 있는 종단점인 집 라우터에 연결합니다. 노트북에 입력한 깨우기 요청은 평범한 터널 트래픽이 되어, 지정한 어떤 목적지로든 전달됩니다. 그 목적지가 이후의 모든 것을 결정합니다.

집 라우터의 LAN 주소에 magic packet 포트로 보냈다면, 라우터는 데이터그램을 받아들일 수 있지만 거기에는 그 포트를 수신 대기하는 것이 없으므로 집 세그먼트로 프레임을 내보내지 않습니다. 터널 안에서 브로드캐스트하면 터널 인터페이스에서 멈춥니다. 라우팅된 터널은 집 배선의 2계층 확장이 아닙니다. 홉 단위로 경로를 따라가면 막다른 길이 분명해집니다.

이것을 판가름하는 확인에는 원격 측에서 명령 하나와 집 측에서 명령 하나가 필요합니다. 요청을 보내고, 그다음 집 세그먼트에서 프레임을 관찰하세요.

보내는 쪽을 집 세그먼트로 옮기세요

터널로 인증이 끝나면 라우터가 직접 깨우기를 할 수 있습니다. OpenWrt는 장치에서 실행되어 프레임을 로컬로 내보내는 Wake-on-LAN 서비스를 문서화하며, 이것이 바로 필요한 형태입니다: 밖에서는 원격 인증, 안에서는 로컬 브로드캐스트.

이 구성은 깨우기 기능을 공용 인터넷에서 멀리 둡니다. 이미 신뢰하는 VPN을 타고 트리거가 흐르므로 인터넷에 새로 노출되는 것은 없습니다. 대안인 포트 포워딩 깨우기 서비스는 작은 편의를 누구나 탐색할 수 있는 인터넷 쪽 종단점과 맞바꿉니다.

순환 의존은 분명히 이름 붙일 가치가 있습니다. 데스크톱에 설치된 VPN 클라이언트는 클라이언트 프로세스에 기계가 실행 중이어야 하므로 그 데스크톱을 깨울 수 없습니다. 원격 진입점은 라우터나 다른 상시 가동 상자에 두고, 데스크톱은 표적일 뿐이게 하세요.

터널을 탓하기 전에 표적을 확인하세요

이 부분은 VPN이 아니라 하드웨어가 결정하고, 전원 상태가 먼저 결정합니다. 어댑터가 깨우기를 지원해야 하고, 펌웨어가 잠든 상태에서도 어댑터에 전원을 공급해야 하며, 운영체제가 그것을 허용하도록 구성되어야 합니다. 일시 중단된 기계는 꺼진 기계와 다른 사례이고, 둘 다 벽에서 전원이 차단된 기계와 다릅니다. 목록의 나머지를 다루기 전에 그 상태를 정리하세요.

프레임을 실제로 받을 어댑터에서 하드웨어 주소를 읽으세요. Ethernet과 Wi-Fi를 모두 갖춘 데스크톱은 흔히 주소가 두 개이고, 그중 하나만 깨우기가 가능할 수 있습니다. 무선 깨우기는 자체 펌웨어 요구 사항을 가진 별개의 기능이므로, Ethernet 깨우기가 된다고 해서 Wi-Fi 깨우기에 대해 말해 주는 것은 없습니다.

먼저 로컬 경로를 증명하세요. 같은 스위치의 다른 기기에서 magic packet을 보내고 기계가 올라오는지 보세요. 그것이 실패하면 터널 디버깅을 아무리 해도 도움이 되지 않으며, 결함은 펌웨어, 어댑터 설정, 전원 상태 중 하나에 있습니다.

깨어난 뒤에는 원하는 서비스에 연결하세요

깨우기는 원격 접속이 아닙니다. 기계가 재개된 뒤에도 서비스를 부팅하고, 주소를 얻고, 실제로 필요한 세션을 받아들여야 합니다. 깨우기가 실패했다고 결론 내리기 전에 그 상태에 도달할 시간을 주세요.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

arp 줄이 유용합니다. 불완전에서 실제 하드웨어 주소로 바뀐 항목은 기계가 재개되어 응답했다는 뜻입니다; 끝내 해석되지 않는 요청은 도달하려던 서비스가 아니라 깨우기 단계를 가리킵니다.

메모에서 단계를 분리하세요: 깨우기, 부팅, 서비스. 두 번째 단계의 실패는 채팅 창에서 보면 첫 번째 단계의 실패와 똑같이 보이며, 오직 로컬 증거만이 둘을 구별합니다.