แอปเดียวผ่าน WireGuard: การผูกไม่ใช่การกำหนดเส้นทาง

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

กลไกนี้มีสองส่วน คือตารางเส้นทางที่ควรใช้เฉพาะทราฟฟิกของทันเนล และกฎที่ส่งต้นทางที่ตรงกันไปที่นั่น

การผูกกำหนดแอดเดรสต้นทางเท่านั้น

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

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

ให้ตารางของตัวเองแก่ทันเนล

wg-quick ติดตั้งเส้นทางตามที่โปรไฟล์บอก การเพิ่ม Table = 40 ใต้ [Interface] จะย้ายเส้นทางเหล่านั้นไปยังตาราง 40 แทนตารางหลัก ยกอินเทอร์เฟซขึ้นและยืนยันว่าเส้นทางมาถึง ip -4 route ls table 40 ควรแสดงเส้นทางของทันเนล และ ip -4 route get 10.66.127.142 แสดงว่าเคอร์เนลแก้ไขเส้นทางหนึ่งในนั้นอย่างไรในขณะนี้ เมื่อเส้นทางอยู่ในตารางของตัวเอง ตารางหลักยังคงทำงานสำหรับทุกอย่างอื่น

ทำเช่นเดียวกันกับ IPv6 แทนการจับคู่คำนำหน้าจำนวนมาก ip -6 rule add from fd00::2/128 lookup 40 ตรึงแอดเดรสเดียวไว้ fc00::/8 อาจชนกับอินเทอร์เฟซอื่นบนโฮสต์และสร้างกฎที่ตรงกับสิ่งที่มากกว่าที่ตั้งใจ

เพิ่มกฎต้นทางและดูตัวนับ

จากนั้นเชื่อมสองส่วนเข้าด้วยกัน ip -4 rule add from 10.66.127.142/32 lookup 40 โดยมีแอดเดรสเดียวกันผูกกับอินเทอร์เฟซ WireGuard ใส่กฎทั้งสองไว้ใน PostUp เพื่อให้การเชื่อมต่อใหม่คืนค่ากฎเหล่านั้น ตรวจสอบด้วยคำขอจริงไม่ใช่การตั้งค่า ip route get 1.1.1.1 from 10.66.127.142 ควรระบุอุปกรณ์ของทันเนล และ curl --interface wg0 ifconfig.me ควรรายงานแอดเดรสของทันเนลไม่ใช่แอดเดรสที่บ้าน

เมื่อยังล้มเหลว ให้อ่าน ip -s rule กฎที่มีอยู่แต่ไม่เคยตรงกับทราฟฟิกจะแสดงตัวนับเป็นศูนย์ ซึ่งแยกกฎที่ผิดออกจากการไม่มีกฎเลย คำสั่งเดียวนี้ประหยัดการเดามากมายว่าแอปละเลยการตั้งค่าอินเทอร์เฟซของตนหรือไม่

กรณีตรงกันข้าม: เก็บ SSH ไว้นอกทันเนล

ปัญหาตรงกันข้ามก็พบได้บ่อยเช่นกัน wg-quick เป็นเจ้าของเส้นทางเริ่มต้น และ เซสชัน SSH ไปยังเซิร์ฟเวอร์ตายกลางทาง กฎของมันอยู่ในหมายเลขลำดับความสำคัญต่ำ จึงต้องประเมินข้อยกเว้นก่อนกฎเหล่านั้น ip rule add dport 22 ipproto tcp table main priority 123 ทำเช่นนั้นบน iproute2 รุ่นใหม่ ในที่ที่ไม่มีตัวเลือก ให้ทำเครื่องหมายโฟลว์ใน nftables แล้วจับคู่เครื่องหมายแทน

ตรวจสอบเส้นทางขากลับด้วย เซสชัน SSH ที่สร้างเสร็จแล้วเงียบไปมักมีเส้นทางแบบอสมมาตร โดยทิศทางหนึ่งออกทางทันเนลและอีกทิศทางออกทางอินเทอร์เฟซกายภาพ ip route get สำหรับแอดเดรสเซิร์ฟเวอร์จะบอกว่าคำตอบจะไปทางใด

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