ทำไม PPP CHAP อย่างเดียวจึงตอบสนองข้อกำหนด MPPE ไม่ได้

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

มีการเจรจาสองครั้งภายในหนึ่งการเชื่อมต่อ PPTP

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

CHAP ธรรมดาคือการแลกเปลี่ยนท้าทาย-ตอบสนองใน RFC 1994 สร้างบนความลับร่วมและไม่มีอย่างอื่น MS-CHAPv2 คือการแลกเปลี่ยนอื่นที่มีข้อความต่างกันและผลลัพธ์ต่างกัน ซึ่งกำหนดมาตรฐานใน RFC 2759 คำที่ใช้ร่วมในสองชื่อคือสิ่งเดียวที่ทั้งสองมีร่วมกันบนสายไฟ ไม่มีชื่อใดบอกว่าการแลกเปลี่ยนสร้างอะไร และนั่นคือส่วนเดียวที่สำคัญ

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

จับคู่วิธีที่กำหนดกับคีย์ที่มันสร้างได้

คีย์ MPPE ไม่ใช่คุณสมบัติของ PPP โดยทั่วไป สำหรับตระกูล Microsoft CHAP การสร้างคีย์ระบุไว้ใน RFC 3079 และรับผลลัพธ์ของการแลกเปลี่ยน MS-CHAP เป็นอินพุตแทนความลับร่วม วิธี EAP ไปถึงจุดเดียวกันด้วยเส้นทางอื่น โดยเซิร์ฟเวอร์รับรองความถูกต้องส่งคีย์กลับมาเป็นแอตทริบิวต์ MS-MPPE-Recv-Key และ MS-MPPE-Send-Key CHAP ธรรมดาไม่ปรากฏในเส้นทางใดเลย และนั่นคือเหตุผลทั้งหมดที่ความไม่สอดคล้องนี้มีอยู่

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

กฎที่ตามมาสั้น ๆ: ถ้าโปรไฟล์กำหนดให้ใช้ MPPE วิธีต้องเป็นรูปแบบของ MS-CHAP หรือวิธี EAP ที่เซิร์ฟเวอร์ส่งคีย์กลับมา การปฏิเสธเฉพาะ MS-CHAPv2 ไม่ได้บังคับสิ่งนั้น เพราะ MS-CHAPv1 ก็สร้างคีย์และยังใช้ได้เว้นแต่จะปฏิเสธแยกต่างหาก การปฏิเสธทั้งสองจะเหลือ CHAP ธรรมดาและ PAP ซึ่งไม่สร้างอะไรและทำให้ข้อกำหนดเป็นไปไม่ได้ ระบุวิธีที่ยอมรับอย่างชัดเจนแทนการไล่รายการวิธีที่ไม่ชอบ การทิ้งข้อกำหนดการเข้ารหัสเพื่อให้ไคลเอนต์เชื่อมต่อได้คือการลดระดับ ไม่ใช่การซ่อม

อ่านตัวเลือกของเซิร์ฟเวอร์ก่อนแก้ไขไคลเอนต์

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

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

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

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

หาความล้มเหลวตามขั้นของ PPP

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

วางแผนทางออกก่อนปิดจุดปลายเก่า

MPPE เป็นกลไกป้องกันลิงก์เชิงประวัติศาสตร์ และการมีอยู่ไม่ได้ทำให้ PPTP เป็นทางเลือกที่สมเหตุสมผลสำหรับการติดตั้งใหม่ แนวทางปัจจุบันของ Microsoft แนะนำคัดค้าน PPTP และ L2TP/IPsec ที่ใช้คีย์ร่วมล่วงหน้าสำหรับการติดตั้งการเข้าถึงระยะไกลใหม่แล้ว การทำให้จุดปลายเก่าคงอยู่คือการตัดสินใจเกี่ยวกับบริการที่มีอยู่ ไม่ใช่แม่แบบสำหรับอันถัดไป

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

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