PPTP ใน Docker ผ่านการรับรองความถูกต้องแต่ไม่รับส่งข้อมูล

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

ห้าการตรวจสอบ ตามลำดับที่ประหยัดเวลาที่สุด

การตรวจสอบ 1: แยกช่องควบคุมออกจากเพย์โหลด

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

ถ้าการเข้าสู่ระบบทำงานและไม่มีแพ็กเก็ตกลับมา ให้สันนิษฐานว่าเป็น GRE ก่อนแล้วจึงพิสูจน์

การตรวจสอบ 2: ยืนยันตัวช่วยในเคอร์เนลของโฮสต์

การติดตามการเชื่อมต่อไม่สามารถเชื่อมโยงการเชื่อมต่อควบคุม TCP เข้ากับโฟลว์ GRE ได้หากไม่มีตัวช่วย โมดูลคือ nf_conntrack_pptp มันอยู่ในเคอร์เนลของโฮสต์ และการโหลดไว้ในอิมเมจคอนเทนเนอร์ไม่ได้ผลอะไรเพราะโมดูลมีผลกับโฮสต์ทั้งเครื่อง lsmod | grep nf_conntrack_pptp บนโฮสต์ Docker คือการตรวจสอบ หากไม่มี modprobe nf_conntrack_pptp จะโหลดมันสำหรับเคอร์เนลที่กำลังทำงานและไม่บอกอะไรเกี่ยวกับการบูตครั้งถัดไป ดังนั้นให้เพิ่มไว้ในการกำหนดค่าของโฮสต์ด้วย

โมดูลที่หายไปเมื่อรีบูตจะกลายเป็นตั๋วเดิมในเดือนหน้า

การตรวจสอบ 3: อ่านนโยบายเคอร์เนลที่ปิดมัน

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

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

การตรวจสอบ 4: มองเส้นทางของคอนเทนเนอร์แยกต่างหาก

ตัวช่วยที่โหลดแล้วไม่ได้สร้างเส้นทาง คอนเทนเนอร์ต้องมีเส้นทางไปยังเซิร์ฟเวอร์ PPTP และการส่งต่อบนโฮสต์ต้องอนุญาต GRE ทั้งสองทิศทาง: iptables -L FORWARD -v -n แสดงว่าโปรโตคอล 47 ถูกยอมรับหรือไม่และตัวนับขยับหรือไม่ กฎ masquerade ของ Docker แปลง TCP และ UDP ไม่ใช่โปรโตคอล 47 ดังนั้นคอนเทนเนอร์แบบบริดจ์อาจต้องมีการยอมรับ forward อย่างชัดเจน และบนโฮสต์บางเครื่องอาจต้องมีกฎแปลงของตัวเอง ตรวจสอบด้วยว่าคอนเทนเนอร์มีการรองรับอุปกรณ์ PPP ที่อิมเมจคาดหวัง

อ่านตัวนับไม่ใช่ข้อความของกฎ กฎที่มีอยู่แต่ไม่ตรงกับอะไรเลยคือเครื่องประดับ

การตรวจสอบ 5: พิสูจน์ว่า GRE ถูกติดตาม แล้วจึงตัดสินใจเรื่อง PPTP

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

PPTP เองเป็นของเก่าและ MS-CHAPv2 อ่อนแอ หากเซิร์ฟเวอร์เสนอ L2TP/IPsec, IKEv2 หรือ WireGuard ด้วย การย้ายไปยังหนึ่งในนั้นจะขจัดปัญหาทั้งประเภทนี้

ในที่ที่ PPTP ต้องอยู่ต่อไป การรันไคลเอนต์บนโฮสต์แทนที่จะเป็นในคอนเทนเนอร์ ขจัด NAT และการกรองหนึ่งชั้น ซึ่งมักเป็นการตัดสินใจที่ถูกกว่า