เซิร์ฟเวอร์ PPTP หลังเราเตอร์บ้าน: แก้ 1723 และ GRE ก่อน

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

สองพาหะ และมีเพียงตัวเดียวที่มีพอร์ต

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

ไฟร์วอลล์ของเซิร์ฟเวอร์เองก็ต้องอนุญาตโปรโตคอล 47 จากที่อยู่ของเราเตอร์ ไฟร์วอลล์โฮสต์ที่รับเฉพาะ 1723/tcp จะสร้างข้อผิดพลาด 619 ซ้ำจากภายใน LAN ทำให้การส่งต่อที่พังกับกฎโฮสต์ที่พังดูเหมือนกัน

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

ถ้าไม่มีโมดูล ให้โหลดด้วย sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre และทำให้การโหลดถาวร เพราะการรีบูตที่ลืมตัวช่วยจะทำให้อุโมงค์ที่ใช้งานได้กลายเป็นข้อผิดพลาด 619 อีกครั้ง กฎส่งต่อควรรับโปรโตคอล 47 ไปยังที่อยู่เซิร์ฟเวอร์เท่านั้น ไม่ใช่ทั้ง LAN RFC 2637 แยกเส้นทางควบคุมและเส้นทางข้อมูล จึงไม่มีหน้าจอส่งต่อพอร์ตใดอธิบาย PPTP ได้ครบ

ช่อง passthrough หรือกฎโปรโตคอลที่ชัดเจน

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

กฎ NAT ปลายทางสำหรับ 1723 ก็มีปัญหาเรื่องเจ้าของ ถ้ากฎเก่ายังส่ง 1723 ไปยังโฮสต์ที่เลิกรันเซิร์ฟเวอร์ แพ็กเก็ตจะตกที่พอร์ตปิด และบริการ PPTP ของเราเตอร์เองก็หยุดตอบ ซึ่งอ่านดูเหมือนไฟร์วอลล์ล้มเหลว แต่จริง ๆ แล้วเป็นเป้าหมายที่ล้าสมัย อ่านกฎและปลายทางก่อนเพิ่มกฎที่สอง บนเราเตอร์ที่จบ PPTP เอง กฎ WAN แข่งกับบริการที่มีในตัว จึงเลือกเจ้าของเดียวสำหรับ 1723 และโปรโตคอล 47

ไคลเอนต์สองตัวหลัง NAT เดียวคือกรณีที่แยกการส่งต่อแบบง่ายออกจากแบบฉลาด การส่งต่อโปรโตคอล 47 โดยไม่เขียนตัวระบุการเรียกใหม่มักทำงานได้ดีกว่าตัวช่วยที่พยายามแก้ให้

วัดอุโมงค์ก่อนโทษเราเตอร์

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

คำนวณตัวเลขแทนการเดา GRE แบบขยายกิน 8 ไบต์ PPP กิน 4 MPPE กิน 4 และหัว IP ด้านนอกกิน 20 อุโมงค์จึงกิน 36 ไบต์ก่อนมีเพย์โหลด บน WAN แบบ PPPoE ที่จบที่ 1492 PPP MTU ที่ใหญ่ที่สุดที่ใส่ได้คือ 1492 ลบ 36 คือ 1456 ตั้ง mtu และ mru เป็นค่านั้นในตัวเลือก PPP แล้วทดสอบซ้ำด้วย ping ที่ไม่แยกส่วน

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Ping วัดเส้นทาง ไม่ได้วัดอุโมงค์: เพย์โหลด 1464 ไบต์บวกหัว IP และ ICMP 28 ไบต์เติมเฟรม 1492 ไบต์พอดี ถ้า ping นั้นล้มเหลว ให้ลดตัวเลขลงจนผ่านแล้วลบ 36 จากผลลัพธ์ MTU ของอุโมงค์ที่ตั้งสูงกว่าขีดจำกัดของเส้นทางทำให้เกิดการแข็งตัวโดยไม่มีบรรทัดล็อกใดกล่าวถึงขนาด

PPTP, L2TP/IPsec หรือ OpenVPN บนเราเตอร์เดียวกัน

เราเตอร์เดียวกันรับอุโมงค์ปกติได้ทั้งสามแบบ และความต่างคือสิ่งที่ต้องสื่อ PPTP ต้องใช้สองกฎในสองชั้นที่ต่างกัน L2TP บน IPsec ต้องใช้ UDP 500 และ 4500 สำหรับแลกกุญแจ และถ้า NAT-T ไม่พาไป ก็ต้องใช้โปรโตคอล 50 สำหรับเพย์โหลด OpenVPN ใช้พอร์ต UDP เดียวและไม่ต้องมีตัวช่วยเลย

คอลัมน์ L2TP ไม่ได้เป็นมิตรกว่า GRE โดยอัตโนมัติ ESP คือโปรโตคอล IP 50 และก็ไม่มีพอร์ต เราเตอร์ที่ติดขัดกับโปรโตคอล 47 จึงอาจติดขัดกับโปรโตคอล 50 ด้วยเหตุผลเดียวกัน NAT-T มีไว้ห่อ ESP ไว้ใน UDP 4500 และเมื่อปลายทั้งสองรองรับ กฎโปรโตคอล 50 ก็ไม่จำเป็น นั่นเป็นคุณสมบัติของปลาย ไม่ใช่ของช่อง PPTP บนเราเตอร์ ยืนยันว่าอุโมงค์แบบไหนที่ไคลเอนต์ตกลงจริงก่อนเขียนกฎให้ทั้งสอง

OpenVPN เป็นตัวเลือกที่มีชิ้นส่วนขยับน้อยที่สุดฝั่งเราเตอร์ พอร์ต UDP เดียว การส่งต่อเดียว ไม่มีตัวช่วยติดตามการเชื่อมต่อ และไม่มีการเขียนตัวระบุการเรียกใหม่ สิ่งที่แลกคือไคลเอนต์ที่ต้องติดตั้งแทนตัวหมุนที่มีในตัว และนั่นมักเป็นเหตุผลเดียวที่ PPTP ยังอยู่ในการสนทนา

อะไรควรซ่อมและอะไรควรเปลี่ยน

การซ่อมการส่งต่อและ MTU ทำให้ได้อุโมงค์ที่ใช้งานได้ ไม่ใช่แบบที่ควรเก็บไว้ การยืนยันตัวตน MSCHAPv2 ของ PPTP ถูกโจมตีได้มาหลายปี และอุโมงค์ที่ใช้งานได้ก็ย้ายข้อมูลรับรองที่กู้คืนได้แบบออฟไลน์ ถ้าอุปกรณ์ปลายทางรัน L2TP/IPsec หรือ OpenVPN ได้ ให้ถือว่าการซ่อมเป็นมาตรการชั่วคราวที่มีวันหมดอายุ

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

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