hostapd และ OpenVPN บน Pi เครื่องเดียว: เส้นทางเริ่มต้นเป็นของใคร

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

สำรวจอินเทอร์เฟซก่อนแก้ไขอะไร

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

อ่านสถานะปัจจุบันก่อนเปลี่ยนแปลง เพราะสี่คำสั่งนี้แยกปัญหาอินเทอร์เฟซออกจากปัญหาการกำหนดเส้นทาง

ip -br addr
ip route show
ip link show master br0
bridge link show

ถ้า br0 มีที่อยู่แต่ไม่มีเส้นทางเริ่มต้น ไคลเอนต์จะไปถึง Pi และไม่ถึงอะไรที่อยู่ถัดออกไป ถ้าอุโมงค์ลงอยู่แต่เส้นทางเริ่มต้นชี้ไปที่ tun0 Pi ก็ไม่มีเส้นทางที่ใช้งานได้เลย และอาการของไคลเอนต์ก็ดูเหมือนกันทุกประการ ทั้งสองกรณีดูเหมือนกันจากโทรศัพท์ จึงต้องอ่านตารางเส้นทางโดยตรง

ให้บริดจ์มีเส้นทางเริ่มต้นที่เป็นของมันเอง

Raspberry Pi OS มักทิ้งบริดจ์ไว้โดยไม่มีเส้นทางเริ่มต้น เมื่อบริดจ์เกิดขึ้นหลังจากเขียนไฟล์อินเทอร์เฟซแล้ว บล็อกนี้อยู่ใน /etc/dhcpcd.conf และควรระบุเราเตอร์ต้นทาง ไม่ใช่ Pi

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

หลัง systemctl restart dhcpcd ip route show default ควรแสดง br0 หนึ่งครั้ง และไม่มีรายการซ้ำจากพอร์ตสาย ตรวจสอบการค้นหาไม่ใช่ตาราง เพราะรายการเก่าอาจอยู่ข้างรายการที่ชนะ ip -4 route get 203.0.113.10 ต้องระบุ br0 ที่อยู่นั้นมาจากช่วงเอกสาร TEST-NET-3 จึงชนกับเซิร์ฟเวอร์จริงไม่ได้ขณะที่คุณอ่านสิ่งนี้

หยุดอุโมงค์ไม่ให้ช่วงชิงเส้นทางไปยังเซิร์ฟเวอร์ของตัวเอง

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

การเปรียบเทียบเส้นทางขนส่งนั้นก่อนและหลังเชื่อมต่ออย่างรวดเร็วคุ้มกับสิบวินาทีนั้น ip -4 route get 203.0.113.10 ควรระบุอุปกรณ์ชั้นล่างในทั้งสองสถานะ มีเพียงเมตริกที่เปลี่ยน ถ้าหลังอุโมงค์ขึ้นแล้วมันระบุ tun0 แสดงว่าเส้นทางโฮสต์ไม่เคยถูกติดตั้ง และการเชื่อมต่อใหม่ครั้งถัดไปจะล้มเหลว

เมื่อมีเพียงพรีฟิกซ์ที่เลือกไว้ควรข้ามอุโมงค์ ให้ใช้ route-nopull และเพิ่มเส้นทางที่ต้องการด้วยมือ หรือส่งชุดที่แคบกว่าจากเซิร์ฟเวอร์ ในการออกแบบนั้นบริดจ์ยังคงเส้นทางเริ่มต้นไว้ และ DNS จะกลายเป็นการตัดสินใจถัดไป การส่งต่อ dnsmasq ไปยังตัวแก้ชื่อในบ้านสมเหตุสมผลเฉพาะกับชื่อที่อาศัยอยู่ที่นั่นจริง

ตัดสินใจเรื่องการส่งต่อและ NAT

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

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

จดตัวเลือกไว้ข้างกฎไฟร์วอลล์ เพราะกฎ NAT ที่มองไม่เห็นในการออกแบบจะอธิบายไม่ได้ในอีกหกเดือน ให้ IPv6 อยู่ในการตัดสินใจเดียวกัน เส้นทาง IPv4 ที่ใช้งานได้ข้างเส้นทาง IPv6 ที่พังยังอ่านได้ว่าพังครึ่งหนึ่งในเบราว์เซอร์

ตรวจสอบจากไคลเอนต์ แล้วย้อนกลับอย่างสะอาด

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

จากนั้นยืนยันว่า Pi ยังมีทางออกของตัวเอง ip route get 203.0.113.10 ควรระบุอุปกรณ์ชั้นล่าง และ ping -c 3 -I br0 203.0.113.10 ควรตอบถ้าเซิร์ฟเวอร์อนุญาต ICMP ถ้าสองขั้นแรกของไคลเอนต์ผ่านและขั้นที่สามล้มเหลว แสดงว่าปัญหาอยู่ที่การส่งต่อหรือ NAT ถ้าขั้นที่สองล้มเหลว บริดจ์หรือ DHCP ยังไม่สมบูรณ์

การย้อนกลับคือการแก้ไฟล์หนึ่งครั้งและสองคำสั่ง ลบบล็อก รีสตาร์ท dhcpcd และแทนที่เส้นทางเริ่มต้นอย่างชัดเจนด้วย ip route replace default via 192.168.50.1 dev br0 ทำก่อนหน้าต่างบำรุงรักษาจะปิด ไม่ใช่หลังจากนั้น เพราะ Pi ที่สูญเสียเส้นทางเริ่มต้นจะเข้าถึงไม่ได้จากเครือข่ายที่คุณจะใช้ซ่อมมัน