วิธีแยกระหว่างเส้นทางที่ VPN ดันมากับเส้นทางแบบคงที่บน Linux

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

ขั้นตอนที่ 1: ตั้งชื่อกลไกที่ติดตั้งคำนำหน้า

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

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

ขั้นตอนที่ 2: เปรียบเทียบตารางตลอดการเชื่อมต่อหนึ่งครั้ง

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

เก็บภาพด้วย ip route show table main > /tmp/route-down.txt เชื่อมต่อ แล้วเก็บภาพอีกครั้ง ทำแบบเดียวกันกับ ip -6 route หากไซต์ใช้ IPv6 เพราะคำนำหน้าที่หายไปตรงนั้นทำให้เกิดความล้มเหลวที่ดูเหมือนไม่เกี่ยวกับการกำหนดเส้นทาง

ขั้นตอนที่ 3: อ่านเมตริก ไม่ใช่แค่การมีอยู่

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

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

ขั้นตอนที่ 4: หารายการที่อายุยืนกว่าอุโมงค์

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

ตรวจสอบฝั่งถาวรในที่ที่ดิสทริบิวชันของคุณใช้ ไม่ว่าจะเป็นยูนิต systemd-networkd โปรไฟล์ NetworkManager หรือสคริปต์ในไดเรกทอรี up ของไคลเอนต์ การแก้ตารางที่ใช้งานอยู่ด้วย ip route del อยู่ได้เพียงถึงการเชื่อมต่อครั้งถัดไป มองการลบนั้นเป็นการทดสอบสมมติฐาน ไม่ใช่การซ่อม

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

ขั้นตอนที่ 5: ยืนยันเส้นทางขากลับก่อนโทษไคลเอนต์

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

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

ขั้นตอนที่ 6: ทดสอบทรัพยากร ไม่ใช่ ping

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

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