L2TP/IPsec ใช้งานไม่ได้: แยก IPsec การยืนยันตัวตนของอุโมงค์ หรือการล็อกอิน PPP

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

สามขั้นของการยืนยันตัวตน สามอัตลักษณ์ที่แตกต่างกัน

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

การเชื่อมต่อควบคุมของ L2TP สามารถเพิ่มการแลกเปลี่ยนคำท้าและคำตอบชุดที่สองแยกต่างหาก ซึ่งขับเคลื่อนด้วยความลับร่วมที่ทั้งสองฝั่งต้องมี

RFC 2661 ทำให้การยืนยันตัวตนของการเชื่อมต่อควบคุมนั้นเป็นทางเลือก ซึ่งอธิบายว่าทำไมข้อผิดพลาดเดียวกันจึงให้อาการต่างกันบนเซิร์ฟเวอร์สองเครื่อง การติดตั้งที่ไม่เคยตั้งค่าความลับของอุโมงค์จะข้ามขั้นนี้ไปทั้งหมด ส่วนการติดตั้งที่ตั้งค่าไว้เพียงฝั่งเดียวจะล้มเหลวก่อนที่ PPP จะถูกเสนอด้วยซ้ำ จากนั้น PPP จะยืนยันผู้ใช้ด้วย PAP, CHAP หรือ MSCHAPv2 และส่งชื่อไปยังที่เก็บบัญชีซึ่งอาจเป็นแบบโลคัล ใน chap-secrets หรือบน RADIUS รหัสผ่านที่ผิด ณ จุดนั้นยังคงทิ้งอุโมงค์ที่ใช้งานได้และเซสชันที่ล้มเหลวไว้กับคุณ

อ่านจุดหยุดก่อนแก้ไขการกำหนดค่า

เริ่มด้วย ipsec --version เพื่อให้รู้ว่าผลลัพธ์สถานะเป็นของ strongSwan หรือ Libreswan จากนั้นอ่านล็อกของเซิร์ฟเวอร์ ไม่ใช่หน้าต่างไคลเอนต์ เพราะเซิร์ฟเวอร์บันทึกว่าขั้นใดปฏิเสธ

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

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

ขั้นแรก: IPsec มีความสัมพันธ์หรือไม่

รัน ipsec statusall บน strongSwan หรือ ipsec whack --status บน Libreswan และมองหาความสัมพันธ์ลูกที่สร้างขึ้นแล้วโดยมีตัวนับที่ไม่เป็นศูนย์ ip xfrm state แสดงมุมมองของเคอร์เนลบนทั้งสองระบบ คู่ SA ที่ติดตั้งแล้วและตัวนับเพิ่มขึ้นหมายถึงขั้นแรกเสร็จสิ้นและคุณไปต่อได้

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

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

ขั้นที่สอง: การเชื่อมต่อควบคุมของ L2TP ยืนยันตัวตนแล้วหรือยัง

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

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

มีเพียงเซสชันที่เริ่มเจรจา PPP เท่านั้นที่ผ่านขั้นของอุโมงค์จริง

ขั้นที่สาม: PPP ปฏิเสธบัญชีหรือไม่

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

บนเซิร์ฟเวอร์ Linux ให้ตรวจสอบไฟล์ตัวเลือกที่เดมอนส่งให้ PPP ซึ่งโดยปกติคือ /etc/ppp/options.xl2tpd และยืนยันว่าวิธีใดได้รับการยอมรับและบัญชีได้รับการแก้ไขที่ใด ชื่อที่มีอยู่ใน RADIUS แต่ไม่มีในไฟล์ความลับภายในเครื่องจะล้มเหลวอย่างสะอาดและดูเหมือนรหัสผ่านที่ผิด จากนั้นตรวจสอบว่าไคลเอนต์เสนอวิธีที่เซิร์ฟเวอร์ยอมรับ ไม่ใช่วิธีที่แข็งแกร่งกว่าซึ่งเซิร์ฟเวอร์ปฏิเสธที่จะเจรจา การเปลี่ยนคีย์ที่แชร์ล่วงหน้าเพื่อซ่อมขั้นนี้ทำให้เสียเวลาช่วงบ่ายและไม่เปลี่ยนแปลงอะไร

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