สองเกตเวย์ หนึ่ง VPN: ทำไม OpenVPN จึงเลือกอัปลิงก์ผิดเส้น

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

ที่อยู่ของอุโมงค์ไม่ใช่ปลายทาง

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

รายการ remote ในโปรไฟล์ระบุปลายทางภายนอก ดังนั้นนั่นคือที่อยู่ที่ต้องปักหมุด และยังเป็นค่าที่เปลี่ยนเมื่อชื่อโฮสต์ถูกแปลงต่างออกไปหรือโปรไฟล์ระบุ remote หลายรายการ

หาที่อยู่ที่ไคลเอนต์เรียกจริง

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

ปักหมุดปลายทางและอ่านลำดับนโยบาย

เส้นทางโฮสต์เจาะจงกว่าเส้นทางเริ่มต้นใด ๆ ดังนั้น /32 สำหรับที่อยู่พีร์จึงชนะภายในตารางที่มีมัน รูปแบบปกติระบุเกตเวย์และอุปกรณ์อย่างชัดเจน:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

เส้นทางนั้นช่วยได้ก็ต่อเมื่อการค้นหไปถึงตารางนั้น กฎนโยบายถูกประเมินตามลำดับและรายการที่ตรงรายการแรกเป็นตัวตัดสิน ดังนั้น กฎที่ส่งทุกอย่างไปยังตารางที่สองจะข้ามเส้นทางโฮสต์ของคุณใน main อ่านกฎก่อนสันนิษฐานว่าเส้นทางนั้นเป็นข้อยุติ:

ip rule show
ip route get 203.0.113.40

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

เมื่อปลายทางเคลื่อนที่

ชื่อโฮสต์ที่แปลงเป็นหลายที่อยู่ทำให้ /32 แบบถาวรใช้ไม่ได้ทันทีที่คำตอบเปลี่ยน โปรไฟล์ที่มี remote หลายบรรทัดมีปัญหาเดียวกัน เพราะไคลเอนต์อาจไปลงที่ใดก็ได้ในนั้น รีเฟรชเส้นทางจากฮุกวงจรชีวิตของไคลเอนต์เองแทนการเพิ่มด้วยมือ สคริปต์ up ที่อ่านพีร์ที่เจรจาแล้วและ ติดตั้งเส้นทางโฮสต์ จะรักษาข้อยกเว้นให้ตรงกับความเป็นจริง และสคริปต์ down ที่เข้าคู่กันก็ลบมันออก

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

แยกนโยบายภายในออกจากกัน

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

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

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