การจำกัด MSS บนเกตเวย์ VPN: แก้อะไรและไม่แก้อะไร
การจำกัด MSS เขียน MSS ใหม่ในการจับมือ TCP เพื่อให้เซกเมนต์พอดีกับอุโมงค์ ไม่เคยแก้ UDP หรือการตรวจ path-MTU ที่เสีย สามการตรวจ ตามลำดับ
คำขอเล็ก ๆ ทำงานได้ การดาวน์โหลดขนาดใหญ่ค้าง และมีคนเสนอการจำกัด MSS ข้อเสนอนั้นถูกบ่อยพอที่จะคุ้มค่าลองตามลำดับที่ถูกต้อง และผิดบ่อยพอที่จะเสียเวลาครึ่งวันถ้านำไปใช้แบบไม่คิด การตรวจสามข้อด้านล่างแยกปัญหาขนาด TCP จริงออกจากปัญหา UDP จากการค้นหา path-MTU ที่เสีย และจากคลัมป์ที่ไม่เคยเห็นการจับมือที่ควรเขียนใหม่
เริ่มจากรูปร่างของความล้มเหลว
ความล้มเหลวด้านขนาดมีลายเซ็น: การเชื่อมต่อสร้างสำเร็จ การพิสูจน์ตัวตนและการตอบกลับเล็ก ๆ สำเร็จ จากนั้นการถ่ายโอนหยุดค้างไม่จำกัดเมื่อต้องการเซกเมนต์ขนาดเต็ม หน้าที่โหลดข้อความได้แต่ไม่เคยทำรูปภาพเสร็จคือความล้มเหลวเดียวกันในขนาดเล็กกว่า ถ้าไม่มีอะไรเชื่อมต่อเลย ปัญหาอยู่ก่อนหน้านั้นในเส้นทาง และการจำกัด MSS จะไม่ช่วย คลัมป์ไม่สามารถซ่อมการจับมือที่ไม่เคยมาถึง
ลายเซ็นนี้มีอยู่เพราะการจับมือคือจุดที่ตกลงขนาดเซกเมนต์ แต่ละฝ่ายประกาศขนาดเซกเมนต์สูงสุดเป็นออปชัน TCP และผู้ส่งเคารพการประกาศของอีกฝ่าย หากเส้นทางไม่สามารถบรรทุกเซกเมนต์ใหญ่ขนาดนั้นได้ ความล้มเหลวจะปรากฏทีหลัง เมื่อผู้ส่งลองสักตัวในที่สุด
จับตาการขนส่งไว้ขณะอ่านอาการนั้น การจำกัด MSS คือการเขียนออปชัน TCP ใหม่ ดังนั้นการโทรเสียงหรือวิดีโอที่ค้างใต้อุโมงค์เดียวกันไม่ใช่ปัญหา MSS และจะไม่ดีขึ้นจากการจำกัดนี้ จดการขนส่งไว้ก่อนแตะออปชัน TCP
ประเมินราคาเส้นทาง แล้วเปรียบเทียบกับอุโมงค์
ตัวเลขสองตัวสำคัญและมักสับสน path-MTU คือแพ็กเก็ตใหญ่ที่สุดที่เส้นทางบรรทุกได้โดยไม่แบ่งส่วน และ MSS ที่ประกาศสำหรับ IPv4 คือค่านั้นลบ 40 ไบต์ของส่วนหัว IP และ TCP หรือลบ 60 สำหรับ IPv6 การห่อหุ้มอุโมงค์กินงบประมาณส่วนหนึ่งก่อนที่แพ็กเก็ตชั้นในจะเริ่ม
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20ping ที่มีบิต do-not-fragment บอกว่าแพ็กเก็ตขนาดเพย์โหลดนั้นอยู่รอดหรือไม่ ปรับขนาดจนกว่าจะล้มเหลวและคุณพบขีดจำกัดเส้นทางจากการทดลองแล้ว เอาต์พุตของ tracepath รายงาน MTU ที่ค้นพบตลอดเส้นทาง ซึ่งเร็วกว่าเมื่อทำงานได้และเชื่อถือได้น้อยกว่าเมื่อฮอปกลางกรองการตรวจ
ตอนนี้ลบภาระส่วนเกินของอุโมงค์ ส่วนหัว IP ชั้นนอก ส่วนหัว UDP และส่วนหัวเฉพาะอุโมงค์ล้วนมาจาก 1500 ไบต์เดียวกัน ดังนั้น MTU ชั้นในที่ใช้ได้บนโครงข่ายอีเทอร์เน็ตทั่วไปจึงต่ำกว่าที่ลิงก์กายภาพบอกเป็นนัย หาก MTU ชั้นในที่คำนวณได้ต่ำกว่าที่เพื่อนของคุณประกาศ คุณพบผู้สมัครคลัมป์จริง ไม่ใช่การเดา หากค่าที่คำนวณได้สูงกว่าการประกาศของเพื่อนอยู่แล้ว ให้หยุดตรงนี้และมองที่อื่น
วางคลัมป์ตรงที่การจับมือผ่าน
คลัมป์ทำงานโดยเขียนออปชัน MSS ในแพ็กเก็ต SYN และ SYN-ACK ใหม่ขณะข้ามเกตเวย์ หากกฎอยู่บนอินเทอร์เฟซที่ไม่มีทิศทางใดผ่านเลย การเจรจาจะเสร็จสิ้นโดยไม่เปลี่ยนและอาการยังอยู่ ดังนั้นตำแหน่งจึงตัดสินผลมากกว่าค่า
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
ทิศทางคืออีกครึ่งหนึ่ง การจำกัดทิศทางเดียวซ่อมครึ่งหนึ่งของโฟลว์และปล่อยที่เหลือล้มเหลวในลักษณะที่ดูเหมือนเป็นช่วง ๆ ดังนั้นใช้กับทั้งสองทิศทางของการรับส่งที่ส่งต่อ รูปแบบคลาสสิกใน Linux สำหรับอินเทอร์เฟซอุโมงค์คือกฎ mangle ที่ตรงกับแพ็กเก็ต SYN:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuสังเกตว่า --clamp-mss-to-pmtu ทำอะไรจริง ๆ: มันได้ค่ามาจาก MTU ของเส้นทาง ซึ่งไม่ใช่ งบประมาณเพย์โหลดจริงของอุโมงค์เสมอไป บนอุโมงค์ที่อิงเส้นทางซึ่งเส้นทางชั้นในและเส้นทางชั้นนอกต่างกัน ค่าที่ชัดเจนซึ่งคำนวณในการตรวจก่อนหน้าคาดเดาได้มากกว่าค่าอัตโนมัติ
ยืนยันด้วยการเชื่อมต่อใหม่ และรักษาข้อมูลป้อนกลับให้มีชีวิต
การเชื่อมต่อที่สร้างแล้วจะเก็บ MSS ที่เจรจาไว้ การทดสอบในเซสชันเดิมจึงไม่พิสูจน์อะไร เปิดการเชื่อมต่อใหม่หลังการเปลี่ยนแปลงและอ่านค่าที่เจรจาโดยตรง แทนที่จะอนุมานจากการถ่ายโอนที่บังเอิญเสร็จ
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSคำสั่งแรกแสดง MSS ของซ็อกเก็ตพร้อมสถานะการคัดค้าน ซึ่งเป็นการยืนยันเร็วที่สุดว่าคลัมป์มีผล คำสั่งที่สองยืนยันว่ากฎที่คุณคิดว่าเพิ่มไปคือกฎที่มีอยู่จริง ในตารางที่วางไว้
จากนั้นปกป้องกลไกที่คุณไม่ได้ซ่อม path-MTU อาศัยข้อความ ICMP fragmentation-needed ไปถึงผู้ส่ง ดังนั้นไฟร์วอลล์ที่ทิ้งข้อความเหล่านี้จะทำลายการถ่ายโอนขนาดใหญ่ต่อไปแม้มีคลัมป์ที่ถูกต้อง อนุญาตข้อความเหล่านี้สำหรับเส้นทางอุโมงค์ หรือยอมรับว่าการจำกัด MSS กำลังชดเชยนโยบายที่คุณเลือกเอง
สุดท้าย จงต้านทานการล่อใจให้ถือคลัมป์เป็นปุ่มปรับแต่ง มันจำกัดขนาดเซกเมนต์ซึ่งสิ้นเปลืองทรูพุตบนเส้นทางที่ไม่เคยต้องการเลย เมื่อใช้หลังการตรวจสามข้อมันคือการซ่อมที่ตรงจุด เมื่อใช้ก่อนมันคือการเปลี่ยนแปลงที่ซ่อนข้อบกพร่องเดิมและเพิ่มตัวแปรที่สองให้ทุกการทดสอบถัดไป การแลกเปลี่ยนนั้นควรทำอย่างตั้งใจ ไม่ใช่โดยปริยาย
จด path-MTU ที่วัดได้ ภาระส่วนเกินอุโมงค์ที่ลบออก กฎที่เพิ่ม และ MSS ที่เห็นหลังจากนั้น ตัวเลขสี่ตัวทำให้เหตุการณ์ครั้งหน้าเป็นการค้นหาแทนการสอบสวน