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

สองข้อความ สองข้อผิดพลาดที่ต่างกัน

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

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

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

โปรโตคอล 47 ไม่ใช่พอร์ต 47

PPTP ใช้ TCP 1723 เพื่อตั้งสายเรียกและ GRE เพื่อบรรทุกเพย์โหลด GRE คือโปรโตคอล IP 47 ไม่ใช่หมายเลขพอร์ต ดังนั้นกฎไฟร์วอลล์ที่เปิดพอร์ต 47 จึงไม่อนุญาตสิ่งที่เป็นประโยชน์

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

สังเกตทั้งสองทิศทางพร้อมกันบนเซิร์ฟเวอร์แทนการเดาว่าฝั่งใดทิ้งทราฟฟิก: tcpdump -ni any port 1723 or proto gre

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

อนุญาต GRE ในจุดที่โฮสต์ส่งต่อจริง

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

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

ทำให้กฎคงอยู่ผ่านบริการไฟร์วอลล์ของการแจกจ่ายแทนการรันซ้ำหลังรีบูตทุกครั้ง บนโฮสต์ nftables จับคู่ ip protocol gre ทั้งในเชน input และ forward

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

ปรับตัวเลือกให้ตรงกับไคลเอนต์ที่คุณมีจริง

วิธีแก้จากรายงานอื่นอยู่ใน /etc/ppp/pptpd-options ซึ่งสูตรปฏิเสธ PAP, CHAP และ MSCHAP แสดงความคิดเห็นบรรทัด require ที่เกี่ยวข้อง และเก็บ MPPE ที่มีสถานะ สูตรนั้นเขียนสำหรับส่วนผสมไคลเอนต์แบบเดียว และการคัดลอกอย่างไม่ลืมหูลืมตาจะทำให้กรณีทั่วไปพัง อ่านบรรทัดการปฏิเสธเป็นข้อความเกี่ยวกับไคลเอนต์ที่ผู้เขียนมี ไม่ใช่คำแนะนำ

ไคลเอนต์ Windows มักต้องใช้ MS-CHAPv2 กับ MPPE-128 รักษาข้อกำหนดเหล่านั้นและลบเฉพาะตัวเลือกที่ไคลเอนต์เจรจาไม่ได้จริง

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

อ่านหมายเลขข้อผิดพลาดของไคลเอนต์

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

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

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

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