Pi ในฐานะไคลเอนต์ VPN: ผู้จัดการหนึ่งตัวหรือสคริปต์ของตัวเอง?

Raspberry Pi ที่ต้องป้องกันเฉพาะทราฟฟิกขาออกของตัวเองมีสองแนวทางที่ใช้ได้จริง คือปล่อยให้ตัวจัดการเครือข่ายเป็นเจ้าของอุโมงค์ หรือเก็บสคริปต์ที่ถืออุโมงค์ไว้เอง ทั้งสองแบบพาทราฟฟิกได้ แต่ล้มเหลวคนละจุด และความล้มเหลวที่คุณวินิจฉัยจากระยะไกลได้ตอนตีสองคือแบบที่ควรเลือก เปรียบเทียบทั้งสองแบบในเรื่องความเป็นเจ้าของ ความหมายของอุโมงค์แบบเต็มเมื่อมี IPv6 และ DNS เข้ามาเกี่ยวข้อง และสิ่งที่เกิดขึ้นในวินาทีที่อุโมงค์หลุด

เจ้าของสองรายสำหรับอุโมงค์เดียว

แนวทาง A คือโปรไฟล์ภายในตัวจัดการเครือข่ายของระบบ ได้แก่โปรไฟล์ OpenVPN ที่นำเข้า หรือการเชื่อมต่อ WireGuard แบบเนทีฟ ซึ่งเปิดใช้งานตอนบูตโดยบริการเดียวกับที่ยก Ethernet และ Wi-Fi ขึ้นมา แนวทาง B คือยูนิตของคุณเองที่รันไคลเอนต์โดยตรง แก้ไขการตั้งค่าตัวแปลงชื่อ และติดตั้งเส้นทางกับกฎไฟร์วอลล์ของตัวเอง ทั้งสองเป็นแนวทางที่ชอบด้วยเหตุผล ต่างกันที่ใครได้รับอนุญาตให้แก้ตารางเส้นทาง

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

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

การนำเข้าสร้างอะไร และไม่สร้างอะไร

บน Raspberry Pi OS Bookworm และรุ่นใหม่กว่า เครื่องมือตั้งค่าเครือข่ายเริ่มต้นคือ NetworkManager โปรไฟล์จึงเป็นบ้านตามธรรมชาติของอุโมงค์ไคลเอนต์ การนำเข้าต้องมีปลั๊กอินที่ตรงกันติดตั้งไว้ หากไม่มี การนำเข้าจะล้มเหลวพร้อมข้อความเกี่ยวกับชนิดการเชื่อมต่อที่ไม่รองรับ ซึ่งเป็นสัญญาณตรงไปตรงมาให้หยุดและติดตั้งปลั๊กอิน

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

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

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

อุโมงค์แบบเต็ม เปรียบเทียบทั้งสองแนวทาง

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

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

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

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

ล้มเหลวแบบเปิดเทียบกับล้มเหลวแบบปิด

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

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

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

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

การเลือกสำหรับ Pi ที่ไม่มีหน้าจอ

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

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