ปลุกคอมพิวเตอร์ที่บ้านที่หลับอยู่ผ่าน VPN: แพ็กเก็ตมาจากไหน
อุโมงค์ไม่สามารถปลุกเครื่องที่มันสิ้นสุดเองได้ วาง magic packet ไว้บน LAN ที่บ้าน ตรวจสอบอะแดปเตอร์และสถานะพลังงาน แล้วจึงเชื่อมต่อ
คุณเชื่อมต่อ เราเตอร์ตอบกลับ และเดสก์ท็อปยังคงมืดอยู่ อุโมงค์ไม่มีปัญหา แพ็กเก็ตที่จะปลุกเครื่องไม่เคยไปถึงเซกเมนต์ที่เครื่องรอฟังอยู่ การไล่เส้นทางย้อนกลับจากเราเตอร์จะทำให้เห็นว่ามันตายตรงไหน
อุปกรณ์สามตัวมีสามหน้าที่ การสับสนระหว่างกันคือสาเหตุปกติที่ทำให้ความพยายามปลุกวนซ้ำไม่จบสิ้น
เริ่มจากไคลเอนต์ระยะไกลแล้วตามเส้นทางไป
จากเครือข่ายโรงแรมคุณเชื่อมต่อกับเราเตอร์ที่บ้าน ซึ่งเป็นปลายทางเดียวที่เปิดอยู่ตลอดในภาพนี้ คำขอปลุกที่พิมพ์บนแล็ปท็อปกลายเป็นทราฟฟิกอุโมงค์ธรรมดา ที่อยู่ไปยังปลายทางใดก็ตามที่คุณระบุ ปลายทางนั้นเป็นตัวกำหนดทุกสิ่งที่จะตามมา
ถ้าคุณส่งมันไปยังที่อยู่ 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 คือบรรทัดที่มีประโยชน์ รายการที่เปลี่ยนจากไม่สมบูรณ์เป็นที่อยู่ฮาร์ดแวร์จริงหมายความว่าเครื่องกลับมาและตอบแล้ว คำขอที่ไม่เคยแก้ได้จะชี้กลับไปที่ขั้นตอนปลุก ไม่ใช่บริการที่คุณพยายามเข้าถึง
แยกขั้นตอนในบันทึกของคุณ: ปลุก บูต บริการ ความล้มเหลวในขั้นที่สองดูเหมือนความล้มเหลวในขั้นแรกจากหน้าต่างแชต และมีเพียงหลักฐานในเครื่องเท่านั้นที่แยกได้