OpenVPN redirect-gateway: แต่ละแฟล็กทำอะไรกับเส้นทาง

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

แต่ละแฟล็กทำอะไรกับเส้นทางเริ่มต้น

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

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

def1 ชนะด้วยความจำเพาะโดยไม่แตะเส้นทางเริ่มต้นของคุณ

เส้นทางกึ่งเริ่มต้นสองเส้นรวมกันครอบคลุมพื้นที่ IPv4 คือ 0.0.0.0/1 และ 128.0.0.0/1 แต่ละเส้นจำเพาะกว่า 0.0.0.0/0 การค้นหาจึงเลือกมันก่อน ขณะที่เส้นทางเริ่มต้นจริงยังอยู่ในตารางสำหรับทุกสิ่งที่ขอความตรงกันที่จำเพาะน้อยที่สุด

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

ทำให้ปลายทางของอุโมงค์เข้าถึงได้

ไคลเอนต์ต้องการเส้นทางไปยังปลายไกลของอุโมงค์ซึ่งไม่ผ่านอุโมงค์เสียเอง OpenVPN ติดตั้งเส้นทางโฮสต์นั้นก่อนจะเปลี่ยนสิ่งอื่นใด และการแก้เส้นทางด้วยมือหรือไคลเอนต์ VPN ตัวที่สองอาจเอามันออกได้ อาการหลังจากนั้นคือการเชื่อมต่อที่รายงานว่าเชื่อมแล้วแต่ไม่ส่งอะไรผ่านไป

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

ip route get 198.51.100.20

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

ทราฟฟิก IPv6 ยังใช้ตารางของตัวเอง

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

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

ip -6 route show default
ip -6 route get 2001:db8::10

พิสูจน์ว่าแอปพลิเคชันใช้อินเทอร์เฟซใด

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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