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

ขั้นตอนที่ 1: จัดทำบัญชีสิ่งที่การเชื่อมต่อเดิมให้มา

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

สำหรับ L2TP/IPsec ให้แยกสองชั้นอย่างชัดเจน ตัวตนของคู่ IPsec พิสูจน์ตัวตนเครื่อง ส่วน PPP พิสูจน์ตัวตนผู้ใช้ โดยปกติใช้ CHAP หรือ MSCHAPv2

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

ขั้นตอนที่ 2: ออกแบบระบบแทนอย่างตั้งใจ

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

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

ขั้นตอนที่ 3: นำไปใช้เป็นระยะและตรวจสอบทั้งการอนุญาตและการปฏิเสธ

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

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

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

ขั้นตอนที่ 4: ปลดระวางเอกลักษณ์เดิม

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

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

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

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

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