Wake-on-LAN ผ่าน VPN ไม่ทำงาน? แพ็กเก็ตกระจายไม่เคยข้ามไป

อุโมงค์เชื่อมต่ออยู่และแชร์ตอบสนอง แต่เครื่องยังหลับอยู่ ต้องส่ง magic packet ในเซกเมนต์ของเป้าหมายเอง จึงควรวางตัวช่วยไว้ที่นั่น

คุณสั่งให้เครื่องที่ออฟฟิศหลับ เชื่อมต่อ VPN จากบ้าน และเครื่องก็ยังปิดอยู่ อุโมงค์เชื่อมต่ออยู่ แชร์ไฟล์ตอบสนอง และหน้า wake-on-LAN ของเราเตอร์รายงานว่าได้ส่งคำขอไปแล้ว ทุกสัญญาณที่มองเห็นบอกว่าเครือข่ายปกติดี และนั่นคือเหตุผลที่กรณีนี้ชวนสับสน: เฟรมที่จะปลุกเครื่องไม่เคยไปถึงเซกเมนต์ที่เครื่องอยู่เลย

อาการชี้ไปที่ซับเน็ต ไม่ใช่อุโมงค์

ปิงไปยังโฮสต์ที่หลับอยู่ล้มเหลว ซึ่งเป็นเรื่องปกติ เครื่องในโหมดสแตนด์บายไม่มีสแตก IP ที่ทำงานอยู่ จึงตอบ ARP หรือ ICMP ไม่ได้ และไม่มีคอนฟิกอุโมงค์ใดเปลี่ยนสิ่งนี้ การทดสอบที่มีประโยชน์คือเครื่องที่สองใน LAN เดียวกันตื่นขึ้นหรือไม่ และหน้าปลุกของเราเตอร์เองใช้ได้กับโฮสต์ที่เสียบอยู่กับมันหรือไม่

เมื่อการทดสอบในเซกเมนต์เดียวกันผ่าน แสดงว่าปัญหาอยู่ที่ขอบเขต ตัวส่งที่คุณใช้อยู่บนอินเทอร์เฟซ VPN และแพ็กเก็ตที่มันสร้างเป็นการกระจายสำหรับลิงก์ท้องถิ่น จึงออกทางอินเทอร์เฟซผิดหรือไม่ออกเลย อุโมงค์ไม่ได้พัง มันกำลังพาประเภทการรับส่งข้อมูลที่ผิด หาอินเทอร์เฟซที่ตัวส่งเลือกก่อนจะเปลี่ยนการตั้งค่าเราเตอร์แม้แต่รายการเดียว

magic packet เป็นเฟรม ไม่ใช่บริการ

เพย์โหลดเริ่มด้วยเฮดเดอร์คงที่หกไบต์ 0xFF ตามด้วยที่อยู่ฮาร์ดแวร์ของการ์ดเป้าหมายซ้ำสิบหกครั้ง ตามด้วยรหัสผ่าน SecureOn สี่ไบต์แบบไม่บังคับ ผู้ส่งมักห่อสิ่งนี้ใน UDP ไปยังพอร์ต 7 หรือพอร์ต 9 แต่หมายเลขพอร์ตเป็นข้อตกลงระหว่างผู้ส่งกับการ์ด ไม่ใช่ตัวรับฟังที่เชื่อมต่อได้ ไม่มีอะไรฟังอยู่ และไม่มีอะไรตอบกลับ

สิ่งที่ปลุกเครื่องคืออินเทอร์เฟซเครือข่าย ซึ่งจ่ายไฟให้วงจรส่วนเล็กน้อยจากรางสแตนด์บายขณะที่ระบบส่วนที่เหลือปิดอยู่ นี่คือเหตุผลที่การตั้งค่าต้องอยู่รอดทั้งการตัดไฟทั้งหมดและการหลับ: เมนบอร์ดที่ตัดไฟสแตนด์บายตอนปิดเครื่องจะไม่มีการ์ดเหลือให้รับอะไรเลย

ทำไมอุโมงค์แบบกำหนดเส้นทางจึงส่งไม่ได้

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

บทความที่เกี่ยวข้อง