L2TP บน Linux โดยไม่ใช้ IPsec: xl2tpd, pppd และ NAT

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

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

สามไฟล์แบ่งงานกัน

xl2tpd ยุติการเชื่อมต่อควบคุมและส่งแต่ละเซสชันให้เดมอน PPP ดังนั้นการกำหนดค่าจึงกระจายอยู่บนสองโปรแกรมที่ไม่เคยอ่านไฟล์ของกันและกัน ตัวรับฟังอยู่ใน /etc/xl2tpd/xl2tpd.conf ภายในส่วน [lns default] ซึ่งตั้งชื่อพูลแอดเดรสด้วย ip range ฝั่งเซิร์ฟเวอร์ด้วย local ip และการส่งต่อให้ PPP ด้วย pppoptfile เปิด require authentication = yes ปล่อย length bit และ flow bit ให้เปิดอยู่ และเลือกพูลที่ไม่มีอย่างอื่นบนโฮสต์ใช้อยู่แล้ว

นโยบาย PPP อยู่ในไฟล์ที่ตัวเลือกนั้นระบุ โดยปกติคือ /etc/ppp/options.xl2tpd: auth การปฏิเสธสำหรับ pap, chap และ mschap require-mschap-v2 MTU และ MRU ที่ 1460 และแอดเดรส DNS ที่ไคลเอนต์เข้าถึงได้หลังลิงก์ขึ้น ข้อมูลรับรองเป็นไฟล์ที่สามอีกครั้ง /etc/ppp/chap-secrets ซึ่งฟิลด์ที่สองต้องตรงกับชื่อส่วน LNS และฟิลด์ที่สี่สามารถปักหมุดแอดเดรสเฉพาะจากพูลได้

ทำไมอุโมงค์จึงเชื่อมต่อแล้วค้าง

เฟรม Ethernet ขนาด 1500 ไบต์ไม่พอดีกับเส้นทางที่ใช้ไบต์ไปกับเฮดเดอร์ของตัวเองแล้ว เฮดเดอร์ IPv4 ชั้นนอกกิน 20 ไบต์ UDP กิน 8 ไบต์ และเฮดเดอร์ L2TP อีกประมาณ 12 ไบต์ เหลือ 1460 ไบต์ให้ PPP และเพย์โหลด การประกาศตัวเลขที่เล็กกว่านั้นใน PPP คือสิ่งที่กันไม่ให้แพ็กเก็ตใหญ่ถูกแบ่งหรือถูกทิ้งอย่างเงียบ ๆ กลางทาง

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

พอร์ตเดียวพาสองบทสนทนา

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

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

ทำให้อุโมงค์มีประโยชน์: การส่งต่อและ NAT

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

บนเซิร์ฟเวอร์ เปิดการส่งต่อด้วย sysctl -w net.ipv4.ip_forward=1 แปลงพูลด้วย iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE จากนั้นรับทราฟฟิกอุโมงค์ขาออกด้วยกฎ FORWARD สำหรับ -i ppp0 -o eth0 และทราฟฟิกย้อนกลับด้วยกฎกระจกพร้อม -m state --state RELATED,ESTABLISHED ทำให้กฎเหล่านี้คงอยู่ข้ามการรีบูต เพราะเซิร์ฟเวอร์ที่กลับมาโดยไม่มีกฎเหล่านี้ดูเหมือนการกำหนดค่า L2TP ที่เสียหายทุกประการ

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

สแตกเปล่าไม่ได้ทำอะไร และจะตรวจสอบอย่างไร

ไม่มีส่วนใดของสแตกนี้เข้ารหัสเฟรม PPP และไม่มีสิ่งใดพิสูจน์ฝั่งไกลว่าเป็นเซิร์ฟเวอร์ที่คุณเลือกจริง MS-CHAPv2 ป้องกันการแลกเปลี่ยนข้อมูลรับรองจากผู้ฟังที่เพียงแค่มองดู แต่ผู้โจมตีที่อยู่ในเส้นทางยังรบกวนเซสชันได้ ไคลเอนต์พื้นเมืองของ Windows เสนอ L2TP เฉพาะร่วมกับ IPsec ดังนั้นให้เผื่อ Linux เฟิร์มแวร์เราเตอร์ และไคลเอนต์จากบุคคลที่สามเป็นคู่ของคุณ มองการกำหนดค่าเปล่าเป็นขั้นตอนการวินิจฉัย ไม่ใช่จุดที่ควรหยุด

ตรวจสอบตามลำดับที่แน่นอน: รัน xl2tpd -D ที่เบื้องหน้า เฝ้าดูบันทึกสำหรับขั้น PPP อ่านแอดเดรสที่ได้รับจาก ip addr ทั้งสองฝั่ง แล้วจับ UDP 1701 เพื่อยืนยันว่าข้อมูลไหลหลังเซสชันขึ้น หากทั้งสี่ตรงกันแต่ทราฟฟิกยังล้มเหลว ความผิดอยู่ที่การเราท์ การทำ NAT หรือ MTU ไม่ใช่ที่ตัว L2TP เอง