VPN ของเกสต์กับ VPN ของโฮสต์: เส้นทางไหนชนะจริง

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

บันทึกการเชื่อมต่อของเกสต์ก่อน

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

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

ตามจุดปลายของเกสต์ออกไปข้างนอก

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

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

เปรียบเทียบบันทึกก่อนและหลัง

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

รักษาความเป็นเจ้าของให้ชัดเจนข้ามการรีสตาร์ต

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

ตัดสินว่าฝ่ายใดเป็นเจ้าของเส้นทางเริ่มต้นและเขียนลงในคู่มือปฏิบัติการ การรีสตาร์ตเกสต์หรือการสลับเครือข่ายบนโฮสต์ที่พลิกความเป็นเจ้าของอย่างเงียบๆ ทำให้เกิดรายงานบั๊กเกี่ยวกับ VPN ที่ไม่เคยเป็นฝ่ายผิด การจัดวางควรอยู่รอดหลังรีบูตโดยไม่มีใครจำได้ว่ามันทำงานได้เพราะอะไร