OpenVPN mssfix: ทำไมไคลเอนต์เครื่องเดียวจึงค้างเมื่อถ่ายโอนไฟล์ขนาดใหญ่

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

ตัวเลือกนี้เขียนอะไรใหม่

mssfix แก้ไขขนาดสูงสุดของ segment ที่ประกาศในการจับมือ TCP ที่ผ่านอุโมงค์ เพื่อให้ฝั่งผู้ส่งเลือก segment ที่พอดีกับงบประมาณที่ห่อหุ้มไว้ มันทำงานกับการจับมือ ซึ่งหมายความว่าการเชื่อมต่อที่เปิดก่อนการเปลี่ยนแปลงจะคงค่าที่ต่อรองไว้

มันไม่ย่อ datagram ของ UDP และไม่ได้ตั้ง MTU ของอุโมงค์ ปัญหาสองอย่างที่ต่างกันให้อาการเดียวกัน คือผู้ส่ง TCP ที่เพิกเฉยต่อขีดจำกัดของเส้นทาง และเส้นทางที่ทิ้งแพ็กเก็ตขนาดใหญ่แบบเงียบ ๆ ไม่ว่าจะขนาดใด mssfix จัดการอย่างแรกและไม่ทำอะไรกับอย่างที่สอง

ความต่างนี้อธิบายการทดลองที่น่าผิดหวัง การตั้งค่าที่เล็กลงบนเส้นทางที่มีหลุมดำเปลี่ยนขนาด segment แต่ไม่เปลี่ยนการทิ้งที่ตามมา การถ่ายโอนจึงล้มเหลวที่จุดอื่น

ขอบเขตคือ TCP ภายในอุโมงค์

มีการเขียนใหม่เฉพาะทราฟฟิก TCP เซสชัน QUIC เกม หรือแอปพลิเคชันที่ส่ง datagram UDP ขนาดใหญ่จะคงขนาดแพ็กเก็ตของตัวเอง และหากการถ่ายโอนเหล่านั้นคือสิ่งที่ค้าง วิธีแก้ก็อยู่ที่ MTU ของอุโมงค์หรือเส้นทางแทน อ่านว่าการถ่ายโอนที่ล้มเหลวใช้โปรโตคอลใดก่อนจะเลือกใช้ตัวเลือก TCP เพราะชั้นที่ผิดก็มีวิธีแก้ของมันเอง

ทิศทางก็สำคัญ การตั้งค่าฝั่งไคลเอนต์มีผลกับทราฟฟิกที่ไคลเอนต์นั้นส่งเข้าอุโมงค์ ขณะที่เซิร์ฟเวอร์ครอบคลุมโฟลว์ที่ส่งต่อให้ไคลเอนต์ หากเฉพาะดาวน์โหลดขาเข้าที่ค้าง ค่าฝั่งไคลเอนต์ก็ไม่ใช่เรื่องทั้งหมด

ตัวเลขและคำสำคัญพกพาไม่ได้

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

ไวยากรณ์มีลักษณะดังนี้:

mssfix 1400 mtu

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

ยืนยันบนไคลเอนต์เครื่องเดียวก่อน

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

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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