การเปลี่ยน dev tap เป็น dev tun เปลี่ยนสิ่งที่อุโมงค์บรรทุก ไม่ใช่แค่ชื่อของมัน อินเทอร์เฟซ TAP ส่งเฟรม Ethernet ให้บริดจ์ ไคลเอนต์จึงทำงานราวกับเสียบอยู่กับสวิตช์ของออฟฟิศ อินเทอร์เฟซ TUN พาแพ็กเก็ต IP ไคลเอนต์จึงต้องมีเส้นทาง และฝั่งไกลต้องมีทางกลับ ไคลเอนต์ แผนที่อยู่ และเส้นทางขากลับของ LAN ล้วนต้องย้ายตามการเปลี่ยนแปลงนี้

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

ทำบัญชีว่าอะไรพึ่งพา Ethernet จริง ๆ

จดรายการแอปพลิเคชัน ไม่ใช่โฮสต์ ระบุว่าแต่ละตัวใช้บริการ TCP หรือ UDP ที่ถูกกำหนดเส้นทาง การค้นหาด้วย broadcast, DHCP จาก LAN ของออฟฟิศ โพรโทคอล Ethernet ที่ไม่ใช่ IP หรือสมมติฐานว่าทั้งสองฝั่งอยู่ในซับเน็ตเดียวกัน การเข้าถึง IP ทั่วไปอยู่รอดได้ในดีไซน์ที่กำหนดเส้นทาง โพรโทคอลที่ต้องใช้เฟรม Ethernet ดิบไม่อยู่รอด และการกำหนดเส้นทางมากแค่ไหนก็ไม่ทำให้มันทำงานได้ แอปพลิเคชันที่พึ่งการค้นหาต้องมีกลไกทดแทนที่ตัดสินไว้ก่อนการสลับ ไม่ใช่ระหว่างนั้น

บัญชีนั้นคือรายการตอบรับด้วย ทุกรายการที่ย้ายไม่ได้จะกลายเป็นข้อยกเว้นที่บันทึกไว้ หรือเหตุผลที่จะคงเซกเมนต์ TAP ขนาดเล็กไว้เพื่อภาระงานนั้นเพียงอย่างเดียว

สร้างแผนที่อยู่และเส้นทางขากลับ

เลือกคำนำหน้าไคลเอนต์ที่ไม่ทับกับ LAN ช่วงบริดจ์เดิม หรือเครือข่ายใดที่ไคลเอนต์เข้าถึงอยู่แล้ว เซิร์ฟเวอร์แบบโทโพโลจีซับเน็ตต้องมีชิ้นส่วนอย่าง dev tun, topology subnet และ server 10.78.0.0 255.255.255.0 แต่นั่นเป็นเพียงชิ้นส่วน ไม่ใช่โปรไฟล์ที่ใช้งานได้ คงนโยบาย TLS ตัวตน การขนส่ง และการเข้าถึงที่อนุมัติไว้รอบ ๆ และใช้คำนำหน้าที่ตรวจสอบแล้วว่าว่าง

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

ทดลองบนพอร์ตรับฟังแยก

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

รวมการทดสอบการเชื่อมต่อใหม่และปริมาณขากลับไว้ด้วย การจับมือที่สำเร็จไม่ได้บอกอะไรเลยว่าอีกฝั่งตอบกลับได้หรือไม่

ย้ายไคลเอนต์เป็นกลุ่มพร้อมการย้อนกลับ

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

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

ปลดบริดจ์หลังการตอบรับเท่านั้น

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

การโยกย้ายเสร็จเมื่อรูปแบบการเข้าถึงที่กำหนดเส้นทางใช้ได้กับบัญชีรายการ ไม่ใช่เมื่ออินเทอร์เฟซ TAP หายไปจากผลลัพธ์ของ ip link

บทความที่เกี่ยวข้อง