เส้นทางเริ่มต้นเดิมของคุณคงอยู่หลัง OpenVPN โดยเจตนา

คุณเชื่อมต่ออุโมงค์ รัน ip route แล้วเกตเวย์เริ่มต้นเดิมยังคงอยู่ที่นั่น ความคิดต่อไปคือไคลเอนต์ล้มเหลวในการเข้ายึดเส้นทาง คุณจึงลบเส้นทางเริ่มต้นด้วยมือและสูญเสียการเชื่อมต่อทั้งหมด รายการนั้นควรอยู่ต่อไป ด้วย redirect-gateway def1 OpenVPN ติดตั้งเส้นทางที่เจาะจงกว่าสองเส้นซึ่งมีลำดับเหนือกว่าเส้นทางเริ่มต้นธรรมดาแทนที่จะแทนที่มัน เกตเวย์เดิมยังอยู่และหยุดรับทราฟฟิกที่คุณกำลังทดสอบ

def1 ทำอะไรจริง ๆ

แฟล็กนี้เพิ่ม 0.0.0.0/1 และ 128.0.0.0/1 ทั้งคู่ชี้ไปที่อุโมงค์ 0.0.0.0/1 รับทุกที่อยู่ที่อ็อกเทตแรกเป็น 0 ถึง 127 และ 128.0.0.0/1 รับ 128 ถึง 255 ดังนั้นทุกปลายทาง IPv4 จึงมีการจับคู่ที่เจาะจงกว่าเส้นทางเริ่มต้นเดิม ความยาวคำนำหน้า ไม่ใช่เมตริก เป็นตัวตัดสินว่าเส้นทางใดชนะ

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

ทำไม /1 ไม่ใช่ /0

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

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

อ่านตารางเส้นทางจริง

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

สิ่งที่สำคัญคือความสัมพันธ์: ครึ่งเส้นที่เฉพาะเจาะจงสองเส้นอยู่เหนือเส้นทางเริ่มต้นทั่วไปหนึ่งเส้น บรรทัดเกตเวย์เดิมยังคงอยู่เพราะไม่มีอะไรแทนที่มัน

ตรวจเส้นทางที่แพ็กเก็ตใช้จริง

เส้นทางที่เจาะจงกว่ายังชนะได้: เส้นทางสำหรับช่วงส่วนตัว ซับเน็ตภายใน หรือที่อยู่ของเซิร์ฟเวอร์ VPN เองยาวกว่า /1 อุโมงค์ต้องการเส้นทางภายนอกไปยังเซิร์ฟเวอร์ของมัน และการส่งการเชื่อมต่อนั้นกลับเข้าไปในอุโมงค์จะทำให้มันพังทันที บน Linux ให้ถามเคอร์เนลแทนการอ่านตารางด้วยตา: ip route get กับปลายทางที่คุณสนใจจะพิมพ์เส้นทางที่เลือก อินเทอร์เฟซ และแหล่งที่มา หากกำหนดค่าการกำหนดเส้นทางตามนโยบายไว้ ให้ตรวจสอบกฎด้วย เพราะกฎสามารถเลือกตารางอื่นก่อนที่จะปรึกษาตารางหลัก

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

def1 ไม่ครอบคลุมอะไร

รายการ IPv4 สองรายการไม่พูดอะไรเกี่ยวกับ IPv6: โฮสต์ที่มีการเชื่อมต่อ IPv6 ยังคงใช้เส้นทางเริ่มต้นของตนเองจนกว่าบางสิ่งจะเปลี่ยนเส้นทางตระกูลนั้นแยกต่างหาก ซึ่งเป็นสาเหตุที่ทราฟฟิกบางส่วนดูเหมือนข้ามอุโมงค์บนเครือข่าย dual-stack ไคลเอนต์และตัวจัดการเครือข่ายอื่นใช้การกำหนดเส้นทางอุโมงค์เต็มรูปแบบต่างกัน และตารางของพวกมันจะไม่ตรงกัน พฤติกรรมของ def1 ที่อธิบายที่นี่เป็นของแฟล็กที่ OpenVPN เอกสารไว้ ไม่ใช่ของทุก VPN บนเครื่อง

kill switch ตอบคำถามที่แตกต่าง: เครื่องทำอะไรเมื่ออุโมงค์หลุด ลำดับความสำคัญของเส้นทางตัดสินว่าทราฟฟิกไปที่ใดในขณะที่อุโมงค์ทำงาน มันไม่ได้ตัดสินว่าไฟร์วอลล์จะทำอะไรหลังจากนั้น ลำดับการทำงาน: อ่านตาราง ยืนยันว่าครึ่งเส้นทั้งสองมีอยู่ รัน ip route get สำหรับปลายทางที่ล้มเหลว ตรวจสอบกฎนโยบาย แล้วดู IPv6 แยกต่างหาก ปล่อยเส้นทางเริ่มต้นเดิมไว้ที่เดิม