ไคลเอนต์ฮอตสปอตบน Pi เข้าไม่ถึง LAN บ้านผ่าน VPN แบบ TUN

ไคลเอนต์ Wi-Fi และ Ethernet ในเครื่องเชื่อมต่อกับฮอตสปอตของ Pi ดึงที่อยู่จากขอบเขต DHCP ของมัน และโหลดหน้าเว็บได้โดยไม่มีปัญหา จากนั้นไคลเอนต์เดียวกันก็หมดเวลาเมื่อเปิดแชร์ไฟล์หรือเว็บยูไอใน LAN ของบ้าน ขณะที่ตัว Pi เองเข้าถึง LAN นั้นผ่านอุโมงค์ ไม่มีอะไรเสียในชั้นไวร์เลส สิ่งที่ขาดคือสัญญาที่มีการเราเตอร์ พรีฟิกซ์ของฮอตสปอตต้องถูกพาเข้าไปในอินเทอร์เฟซ TUN และมีบางอย่างฝั่งบ้านต้องรู้วิธีส่งคำตอบกลับมา ทั้งสองครึ่งต้องมีอยู่ก่อนที่แพ็กเก็ตเดียวจะเดินทางไปกลับได้ครบ

สามการเชื่อมต่อกับสามงานที่ต่างกัน

บริดจ์ Ethernet ของลินุกซ์ส่งต่อเฟรมตาม MAC ปลายทาง OpenVPN ในโหมด TUN พาแพ็กเก็ต IP และไม่มีชั้น MAC เลย การเพิ่มบริดจ์ในเครื่องจึงไม่ลงทะเบียนอุโมงค์เป็นพอร์ต เอกสาร TUN/TAP ของเคอร์เนล อธิบายการแยกนั้น อุปกรณ์ TAP ดูเหมือนอินเทอร์เฟซ Ethernet อุปกรณ์ TUN ไม่เป็นเช่นนั้น การออกแบบที่บริดจ์สองพอร์ตในเครื่องแล้วเราเตอร์ต่อ คือเราเตอร์ ไม่ว่าชื่ออินเทอร์เฟซจะว่าอย่างไร

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

เก็บโมเด็มไว้นอกบริดจ์ของไคลเอนต์ด้วย การเชื่อมต่อ PPP ไม่ใช่อุปกรณ์ Ethernet ที่ติดป้ายอื่น และตรรกะเส้นทางเริ่มต้นที่เอกสารของ pppd ระบุไว้ทำงานหลังการเจรจา IPCP และถอนเส้นทางของมันเมื่อลิงก์นั้นล่ม การคัดลอกเทมเพลต DHCP และเปลี่ยนชื่อทุก usb0 เป็น ppp0 ไม่ได้พิสูจน์อะไรเกี่ยวกับเกตเวย์ เมตริก หรือวงจรชีวิต

เลือกพรีฟิกซ์ก่อนแก้ไขคอนฟิกใด ๆ

พรีฟิกซ์ที่ทับซ้อนกันทำให้เสียเวลามากกว่ากฎไฟร์วอลล์ เพราะการทับซ้อนส่งการค้นหาเส้นทางไปยังอินเทอร์เฟซผิดแม้อุโมงค์จะแข็งแรง เริ่มจากการแสดงรายการสิ่งที่มีอยู่แล้วบน Pi แล้วอ่านผลลัพธ์เป็นสี่สระแยกกัน

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

สระแรกคือที่อยู่ underlay ที่ผู้ให้บริการให้โมเด็ม ต้องอยู่นอกแผนใดที่หันหาไคลเอนต์ สระที่สองคือซับเน็ตอุโมงค์ที่เซิร์ฟเวอร์เลือก มักเป็น /24 ส่วนตัวของมันเอง สระที่สามคือบริดจ์ฮอตสปอต และสระที่สี่คือพรีฟิกซ์บ้านที่คุณต้องการเข้าถึง ในเส้นทางนี้ฮอตสปอตได้ 172.28.90.0/24 โดยมีบริดจ์ที่ 172.28.90.1 และ LAN บริการของบ้านคง 192.168.77.0/24 ซึ่งหลีกเลี่ยงค่าเริ่มต้น 192.168.1.0/24 และ 10.0.0.0/24 ที่เราท์เตอร์ผู้บริโภคมาพร้อม และช่วงผู้ให้บริการ 100.64.0.0/10

ประกาศที่อยู่บริดจ์เป็นเกตเวย์ในขอบเขต DHCP ของฮอตสปอตเท่านั้น อย่าให้ที่อยู่บ้านเป็นเกตเวย์แก่ไคลเอนต์ฮอตสปอต เพราะพราะพวกเขามีเส้นทางชั้นลิงก์ไปยังเซกเมนต์นั้น

เราเตอร์แต่ละทิศทางบนฝั่งที่เป็นเจ้าของ

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ถ้า ip route get ยังรายงานอินเทอร์เฟซ underlay ให้หยุดตรงนั้น ไม่มีอะไรต่อไปในเส้นทางจะซ่อมการค้นหาที่ผิดได้

อุปกรณ์ในบ้านไม่มีเส้นทางไปยัง 172.28.90.0/24 คำตอบของพวกเขาจึงตามเกตเวย์เริ่มต้นและตายที่เราท์เตอร์ มีการซ่อมสองแบบที่รองรับ หรือเพิ่มเส้นทางสแตติกบนเราท์เตอร์บ้านที่ชี้พรีฟิกซ์ฮอตสปอตไปยังที่อยู่ LAN ของเซิร์ฟเวอร์ VPN หรือเมื่อเซิร์ฟเวอร์เองเป็นเกตเวย์ ให้ลงทะเบียนพรีฟิกซ์ไคลเอนต์ในตารางเราเตอร์ของเซิร์ฟเวอร์เอง ในโหมดหลายไคลเอนต์ของ OpenVPN ไดเรกทอรีเฉพาะไคลเอนต์พาความสัมพันธ์นั้น ไฟล์ที่ตั้งชื่อตามชื่อสามัญของใบรับรองไคลเอนต์ มี iroute 172.28.90.0 255.255.255.0 พร้อมบรรทัด route ที่ตรงกันซึ่งติดตั้งในเคอร์เนลเซิร์ฟเวอร์ เส้นทางเคอร์เนลที่เดาเอาบนเซิร์ฟเวอร์ไม่ใช่ข้อความเดียวกับการบอกเซิร์ฟเวอร์ว่าไคลเอนต์ใดเป็นเจ้าของพรีฟิกซ์

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

เปิดการส่งต่อโดยไม่เดาไฟร์วอลล์

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

มองหากฎยอมรับจาก br0 ไปยัง tun0 และทิศทางคำตอบที่ตรงกัน และกฎ postrouting ที่อาจเขียนที่มาใหม่ ถ้านโยบายเชนเป็น drop และไม่มีกฎใดตรง ให้เพิ่มการยอมรับแบบแคบแล้วทดสอบใหม่แทนการพลิกนโยบายเป็น accept

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

ตรวจสอบการไปกลับ แล้วทำลายมันโดยเจตนา

ทดสอบจากไคลเอนต์ฮอตสปอต ไม่ใช่จาก Piเพราะทราฟฟิกของ Pi เองข้ามทั้งเส้นทางไปและกลับ สังเกตอินเทอร์เฟซทั้งสองขณะไคลเอนต์หนึ่งพยายามเข้าถึงบริการในบ้าน

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

อ่านแคปเจอร์ทั้งสองด้วยกัน คำขอที่ br0 ซึ่งไม่เคยปรากฏที่ tun0 หมายความว่า Pi ไม่ส่งต่อหรือเส้นทางชี้ไปที่อื่น คำขอที่ tun0 โดยไม่มีคำตอบหมายความว่าฝั่งบ้านไม่มีเส้นทางขากลับหรือเซิร์ฟเวอร์กรองแพ็กเก็ต คำตอบที่ tun0 ซึ่งไม่ปรากฏอีกที่ br0 หมายความว่ากฎกรองย้อนกลับหายไป ซึ่งอุโมงค์ดูสมบูรณ์แบบแต่ไคลเอนต์ยังไม่เห็นอะไร

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

ยอมรับการออกแบบเมื่อไคลเอนต์ฮอตสปอตแก้ชื่อบ้านได้ เปิดบริการ TCP ได้ และรักษาเซสชันให้มีชีวิตข้ามการเชื่อมต่อโมเด็มหนึ่งครั้ง หากแอปพลิเคชันต้องการการค้นพบระดับ Ethernet ในเซกเมนต์บ้านจริง ๆ ให้เลือกการออกแบบ Layer 2 ที่รองรับ แทนการอธิบายบริดจ์ในเครื่องว่าถูกบริดจ์แล้วรอให้การออกอากาศปรากฏ