ทดสอบการกำหนดเส้นทาง VPN ในเนมสเปซโดยไม่แตะเส้นทางของโฮสต์

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

สองวิธีสร้างแล็บเดียวกัน และเมื่อใดแต่ละวิธีชนะ

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

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

หนึ่งบริบทต่อบทบาท เชื่อมต่อโดยเจตนา

สร้างหนึ่งเนมสเปซต่อบทบาทและย้ายปลายแต่ละข้างของทุกคู่ veth เข้าไปในบริบทที่เป็นเจ้าของ สี่คำสั่งแรกเพียงพอที่จะเห็นรูปร่าง:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

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

บทบาทการส่งต่อคือจุดที่แล็บน่าสนใจ

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

ตรวจสอบตัวนับการส่งต่อหลังแพ็กเก็ตทดสอบ เพราะกฎที่ไม่เคยตรงกันและกฎที่ทิ้งแพ็กเก็ตดูเหมือนกันในตารางเส้นทาง มีเพียงตัวนับเท่านั้นที่แยกทั้งสอง

บันทึกเส้นฐาน แล้วทำลายหนึ่งเส้นทาง

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

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

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

การทำความสะอาดคือสิ่งที่ทำให้การรันครั้งถัดไปทำซ้ำได้

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

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