วิธีตรวจว่า Mesh Wi-Fi ดาวเทียมใช้เราเตอร์ VPN หรือไม่
ตามดูเกตเวย์เริ่มต้น โหมดส่งต่อของโหนด และตารางสถานะของเราเตอร์ เพื่อพิสูจน์ว่าลูกข่ายของดาวเทียม Mesh ออกผ่าน VPN หรือไม่
ดาวเทียมที่ตอบชื่อ Wi-Fi เดียวกับเราเตอร์หลักแทบไม่บอกอะไรเลยว่าแพ็กเก็ตของลูกข่ายไปที่ไหน โหนดคือวิทยุและบริดจ์จนกว่าจะพิสูจน์เป็นอย่างอื่น สิ่งที่ตัดสินทางออกคือเกตเวย์เริ่มต้นที่ลูกข่ายแต่ละเครื่องได้รับและโหมดส่งต่อของโหนดที่อยู่ข้างหน้า ทำการตรวจทั้งห้านี้จากลูกข่ายออกไป แล้วคุณจะได้คำตอบที่โต้แย้งได้ ไม่ใช่ความรู้สึกจากสปีดเทสต์
อ่านเกตเวย์ที่ลูกข่ายได้รับจริง
บนลูกข่าย พิมพ์ตารางเส้นทางและตารางเพื่อนบ้าน เส้นทางเริ่มต้นระบุที่อยู่ที่ส่งต่อทราฟฟิก ส่วนรายการเพื่อนบ้านระบุ MAC ที่เป็นเจ้าของที่อยู่นั้น ใช้ลูกข่ายไม่ใช่รายการอุปกรณ์ของเราเตอร์ เพราะ รายการอุปกรณ์แสดงการเชื่อมโยง ไม่ใช่เส้นทาง
ip route show default
ip -6 route show default
ip neigh showWindows พิมพ์ข้อเท็จจริงเดียวกันในอีกรูปแบบ: ipconfig /all ให้เกตเวย์เริ่มต้น และ arp -a ให้ MAC บน macOS route -n get default และ arp -an ครอบคลุมเรื่องเดียวกัน
เปรียบเทียบเกตเวย์นั้นกับสองที่อยู่ที่คุณรู้อยู่แล้ว คือที่อยู่ LAN ของเราเตอร์หลักและที่อยู่จัดการของดาวเทียม ถ้าเกตเวย์คือที่อยู่ LAN ของเราเตอร์ ลูกข่ายถูกบริดจ์ไปยังเราเตอร์ และนโยบายของเราเตอร์สำหรับเครือข่ายนั้นใช้ตามเดิม ถ้าเกตเวย์คือที่อยู่ของดาวเทียม ดาวเทียมกำลังเราเตอร์ และเราเตอร์ไม่เคยเห็นแพ็กเก็ตของลูกข่ายเป็นทราฟฟิก LAN การตัดสินใจต้องเกิดบนโหนด ไม่อย่างนั้นก็ไม่เกิดเลย
ยืนยันว่าโหนดอยู่ในโหมดใดจริง
ผลิตภัณฑ์ Mesh ใช้สามคำซ้ำสำหรับพฤติกรรมที่ต่างกัน จึงควรเชื่อเส้นทางของแพ็กเก็ตมากกว่าป้ายในแอป โหมดบริดจ์หรือแอ็กเซสพอยต์ส่งต่อเฟรม โหมดเราเตอร์ปิดซับเน็ตและรัน DHCP โหมดแขกมักวางลูกข่ายไว้ใน VLAN แยกที่มีกฎของตัวเอง โหนดในโหมดเราเตอร์ที่อยู่หลังเราเตอร์อีกตัวคือดับเบิล NAT และลูกข่ายมาถึงเราเตอร์ VPN โดยถูกแปลงที่อยู่ไปแล้ว ซึ่งทำให้โยบายที่อิงที่อยู่ต้นทางไร้ผล
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
เพื่อยืนยัน MAC ให้อ่านป้ายบนโหนดและเทียบกับ ip neigh ผู้ผลิตพิมพ์ MAC หลักและสร้าง MAC ของวิทยุแต่ละตัวโดยเพิ่มหนึ่งไบต์ หลักสุดท้ายจึงต่างกัน ให้เทียบคำนำหน้าไม่ใช่ทั้งที่อยู่ ถ้า MAC ของเกตเวย์เป็นของอินเทอร์เฟซ LAN ของเราเตอร์ แสดงว่าโหนดไม่ได้ทำเราเตอร์ให้ลูกข่ายเครื่องนั้น
พิสูจน์ทางออกที่เราเตอร์ ไม่ใช่ด้วยสปีดเทสต์
สถานะฝั่งเราเตอร์เป็นที่เดียวที่แสดงการแปลงที่อยู่ บน OpenWrt ให้ลิสต์กฎนโยบายและตารางเส้นทาง จากนั้นยืนยันว่าอุโมงค์มี handshake ใหม่:
ip rule show
ip route show table all | grep default
wg showบน pfSense หรือ OPNsense หลักฐานเดียวกันอยู่ใน pfctl -sr สำหรับกฎ pfctl -ss สำหรับสถานะที่ใช้งานอยู่ และหน้าสถานะ WireGuard สำหรับตัวนับพีร์ ตาม เอกสารไคลเอนต์ WireGuard. กรองตารางสถานะด้วยที่อยู่ของลูกข่าย ถ้าสถานะแสดงลูกข่ายถูกแปลงเป็นที่อยู่ของอุโมงค์ ทราฟฟิกอยู่ในอุโมงค์ ถ้าแสดงที่อยู่ WAN ก็ไม่ได้อยู่ ไม่ว่าป้ายบนแดชบอร์ดจะว่าอย่างไร
traceroute จากลูกข่ายเพิ่มข้อเท็จจริงที่ตารางสถานะให้ไม่ได้ นั่นคือฮอปแรก ถ้าฮอปแรกคือที่อยู่ LAN ของเราเตอร์ ลูกข่ายไปถึงเราเตอร์โดยตรง ถ้าเป็นที่อยู่ของโหนดตามด้วยฮอปส่วนตัวอีกหนึ่งฮอป คุณอยู่ในเซกเมนต์ที่ถูกเราเตอร์ และฮอปที่สองคืออุปกรณ์ที่ต้องถือโยบาย
ตรวจว่าโหนดแจกอะไรนอกจากที่อยู่
ออปชัน DHCP เดินทางมากับสัญญาเช่า โหนดที่ให้ DHCP เองจึงให้ DNS ของตัวเองและประกาศเราเตอร์ IPv6 ของตัวเองได้ด้วย ลูกข่ายจึงออกผ่านอุโมงค์ได้และยังส่งคำถามไปยัง resolver บนโหนด หรือรับที่อยู่ IPv6 สาธารณะที่โยบายของอุโมงค์ไม่เคยครอบคลุม พิมพ์ทั้งสองอย่างบนลูกข่าย:
cat /etc/resolv.conf
ip -6 addr show scope globalถ้า resolver คือโหนดและโหนดส่งต่อไปยังเราเตอร์ DNS ก็ตามอุโมงค์ ถ้าโหนดแก้ชื่อเองในเครื่องหรือชี้ไปที่ resolver ของผู้ให้บริการ คำถามก็ออกนอกอุโมงค์แม้ HTTP จะไม่ทำเช่นนั้น IPv6 ก็ควรได้รับการทดสอบเดียวกัน ที่อยู่สาธารณะบวกเส้นทางเริ่มต้นที่ข้ามอุโมงค์คือการรั่วไหล และเฟิร์มแวร์ Mesh มักเปิด IPv6 ไว้ขณะที่นโยบาย VPN ครอบคลุมแค่ IPv4
ตัดอุโมงค์โดยเจตนา แล้วจดผลลัพธ์ไว้
ลดอุโมงค์ลงและเฝ้าดูลูกข่ายที่เชื่อมกับโหนดนั้น ไม่ใช่ลูกข่ายที่นั่งข้างเราเตอร์ ping และ curl ด้วยเวลาหมดเวลาสั้น ๆ ก็พอ คำถามคือทราฟฟิกหยุดหรือถอยกลับไปที่ WAN หยุดอุโมงค์ด้วยคำสั่งบริการของเราเตอร์เอง เช่น wg-quick down wg0 หรือการหยุดบริการ OpenVPN และทำให้การทดสอบสั้นเข้าไว้
ถ้าลูกข่ายยังทำงานอยู่ แสดงว่าโหนดหรือเราเตอร์ล้มเหลวแบบเปิดสำหรับเซกเมนต์นั้น และ mesh ได้ยกเลิก kill switch ไปเงียบ ๆ นำอุโมงค์กลับมา ยืนยันว่าตัวนับ handshake ขยับแล้ว และทำการตรวจตารางสถานะจากขั้นที่สามซ้ำ
จดหนึ่งแถวต่อโหนด: ป้าย SSID ที่อยู่เกตเวย์ คำนำหน้า MAC ทางออกยืนยันว่าใช่หรือไม่ IPv6 ครอบคลุมหรือไม่ และพฤติกรรมเมื่ออุโมงค์ลง การโรมมิ่งคือจุดที่คำตอบเปลี่ยน ดังนั้นทดสอบห้องที่คุณใช้จริง เมื่อแถวหนึ่งไม่ตรงกับแถวอื่น โหนดนั้นคือสิ่งที่ต้องตรวจสอบ และการแก้ไขเป็นของอุปกรณ์ที่ถือเกตเวย์ของแถวนั้น