L2TP โปรไฟล์ชั้นไหนที่เสียจริง ๆ

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

ชื่อโปรโตคอลเดียวกันซ่อนบทสนทนาที่ต่างกันสี่แบบ

ตั้งชื่อชั้นก่อนจะเปลี่ยนการตั้งค่า

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

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

เปรียบเทียบโปรไฟล์กับไคลเอนต์ปัจจุบัน

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

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

ตัวเลือกเก่าไม่กลับมาเพราะถูกเปิดใช้

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

การซ่อมด้วยการเปิดทุกอย่างเปลี่ยนไปไกลกว่าความล้มเหลวจริงมาก และทำให้คุณบอกไม่ได้ว่าอะไรที่แก้มัน

นำเสนอการย้ายระบบเป็นโครงการ

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

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

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