ฮอตสปอต VPN แบบบริดจ์: โทรศัพท์ใช้เส้นทางเริ่มต้นใด
เส้นทางเริ่มต้นของ Pi ไม่ใช่เกตเวย์ของโทรศัพท์ แยกการตัดสินใจสองอย่างออกจากกัน เก็บอัปลิงก์ไว้นอกบริดจ์ และทดสอบลีสก่อนอุโมงค์
โทรศัพท์บนฮอตสปอตแบบบริดจ์ของคุณได้ที่อยู่และเกตเวย์มาจากที่ใดที่หนึ่ง และนั่นไม่ใช่เส้นทางเริ่มต้นของ Pi การเปลี่ยนเส้นทางเริ่มต้นของ Pi เปลี่ยนว่า Pi ส่งทราฟฟิกของตัวเองไปที่ใด โทรศัพท์ยังคงใช้เกตเวย์ที่ได้รับบอก และเมื่อเกตเวย์นั้นอยู่บน LAN ระยะไกล เฟรมของมันก็เพียงข้ามบริดจ์ สองผู้บริโภค สองการตัดสินใจ การแยกสองอย่างนี้อธิบายรายงานส่วนใหญ่เกี่ยวกับฮอตสปอตที่ไม่มีอินเทอร์เน็ตในขณะที่ Pi เองปกติดี
สองอุปกรณ์ สองการตัดสินใจเรื่องเกตเวย์ที่ต่างกัน
Pi มีสแตก IP และเส้นทางเริ่มต้นของตัวเอง โทรศัพท์มีสแตก IP และเส้นทางเริ่มต้นของตัวเอง
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
ตารางนั้นคือแบบจำลองทั้งหมด เกตเวย์ของโทรศัพท์คือที่อยู่บน LAN ระยะไกล และเฟรมของมันถูกส่งต่อที่ชั้น 2 ไปยังเราเตอร์นั้น เส้นทางเริ่มต้นของ Pi เกี่ยวกับการขนส่งภายนอกของ Pi เอง ซึ่งต้องไปถึงเพียร์ VPN ผ่านอัปลิงก์การเดินทาง
บริดจ์ส่งต่อเฟรม ไม่ได้เราเตอร์แพ็กเก็ต
บริดจ์ Linux ส่งต่อเฟรม Ethernet ตาม MAC ปลายทาง และนั่นคือทั้งหมดที่ทำระหว่างพอร์ตของมัน เฟรมของโทรศัพท์ที่ส่งถึง MAC ของเราเตอร์ระยะไกลจะถูกสลับไปที่พอร์ต TAP และข้ามอุโมงค์โดยไม่แตะตารางเราเตอร์ของ Pi นั่นคือเหตุผลที่เส้นทางเริ่มต้นที่เสียของ Pi อาจปล่อยให้โทรศัพท์ทำงานได้ และนั่นคือเหตุผลที่เส้นทางที่ถูกต้องไม่อาจแก้โทรศัพท์ที่ได้เกตเวย์ผิด
TAP พาเฟรม Ethernet และเป็นพอร์ตบริดจ์ได้ TUN พาแพ็กเก็ต IP และเป็นไม่ได้ หากการออกแบบของคุณแทนที่กันและกัน บริดจ์ก็ไม่ใช่บริดจ์ และส่วนที่เหลือใช้ไม่ได้
ตัดสินใจว่าใครแจกลีสของโทรศัพท์
ตัวเลือก 3 ของ DHCP คือตัวเลือกเราเตอร์ และบอกไคลเอนต์ว่าจะใช้เกตเวย์ใดสำหรับซับเน็ตของตน เมื่อเซิร์ฟเวอร์ DHCP ของ LAN ระยะไกลเป็นผู้แจกรายเดียว โทรศัพท์ได้เกตเวย์ระยะไกลและการออกแบบสอดคล้องกัน เมื่อมีอย่างอื่นฝั่งการเดินทางตอบก่อน โทรศัพท์ได้เกตเวย์ท้องถิ่น ทราฟฟิกอินเทอร์เน็ตออกทางอัปลิงก์การเดินทาง และทราฟฟิกไปยัง LAN ระยะไกลไม่มีเส้นทางเลย
รันผู้แจกรายเดียวสำหรับโดเมนแพร่กระจายนั้น และบันทึกว่ามันแจกอะไร
Pi เป็นกรณีแยก แม้จะได้ที่อยู่จากลีสเดียวกัน ตัดสินใจอย่างตั้งใจว่าควรติดตั้งเส้นทางที่ลีสเสนอหรือไม่ เพราะเส้นทางเริ่มต้นระยะไกลที่นำเข้าอาจลากการขนส่ง VPN ของ Pi เองเข้าไปในอุโมงค์ที่มันพยายามทำให้มีชีวิตอยู่ ด้วย systemd-networkd การตัดสินใจนั้นคือ UseRoutes= ในส่วน DHCP ด้วย dhclient คือตัวเลือก routers ในรายการคำขอ
เก็บอัปลิงก์ไว้นอก LAN แบบบริดจ์
อินเทอร์เฟซที่พาการเชื่อมต่อ VPN ภายนอกของ Pi ต้องไม่กลายเป็นพอร์ตบริดจ์ หากเป็นเช่นนั้น การขนส่งที่เข้ารหัสจะถูกสลับเข้า LAN ที่ขยายออก และอุโมงค์จะพาแพ็กเก็ตภายนอกของตัวเอง ซึ่งล้มเหลวในลักษณะที่ดูเหมือนแพ็กเก็ตหายมากกว่าลูป เก็บความสามารถ AP และการสนับสนุนบริดจ์ให้ชัดเจนด้วย อินเทอร์เฟซไร้สายในโหมด station ปกติเป็นพอร์ตบริดจ์ไม่ได้ เพราะส่วนหัว 802.11 ไม่มีที่สำหรับ MAC ที่สองซึ่งบริดจ์ต้องการ
กำหนด โดเมนแพร่กระจายที่ขยายออก แผนที่อยู่หนึ่งแผน และการกรองเฟรมที่คุณต้องการจริง ๆ การอนุญาตให้ตัวรับฟัง VPN บน Pi ไม่ได้ให้สิทธิ์ไคลเอนต์แบบบริดจ์ทุกตัวเข้าถึงบริการจัดการของ Pi สิ่งเหล่านั้นเป็นกฎแยกกัน และการถือเป็นหนึ่งเดียวคือวิธีที่ฮอตสปอตกลายเป็นประตูเปิดอย่างเงียบ ๆ
ทดสอบสี่อย่างแยกกันเมื่อมันเสีย
เมื่อโทรศัพท์ไปไม่ถึง LAN ระยะไกล การสังเกตสี่อย่างแยกสาเหตุ รันตามลำดับนี้และหยุดที่อย่างแรกที่ล้มเหลว
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpเริ่มจากลีส: โทรศัพท์ถือที่อยู่และเกตเวย์บนซับเน็ตระยะไกลหรือไม่ จากนั้นดูบริดจ์ และยืนยันว่าพอร์ต AP และพอร์ต TAP ส่งต่อทั้งคู่ จากนั้นอ่านตารางเพื่อนบ้าน เพราะรายการที่ยังแก้ไม่ตกสำหรับเราเตอร์ระยะไกลหมายความว่าเฟรมออกไปและไม่มีอะไรตอบ สุดท้ายสังเกตเฟรมบนบริดจ์ขณะโทรศัพท์ ping ซึ่งบอกคุณว่าความผิดอยู่ใต้ IP หรือไม่
บันทึกว่าอุปกรณ์ใดเป็นเจ้าของเส้นทางเริ่มต้นแต่ละเส้นเมื่อเสร็จ เอกสารหนึ่งบรรทัดเปลี่ยนทางออกท้องถิ่นเทียบกับระยะไกลให้เป็นการตัดสินใจของไคลเอนต์อย่างตั้งใจ และข้อมูลอ้างอิงบริดจ์ก็ควรเก็บไว้ข้าง ๆ