Jumbo frame ไม่ได้ทำให้เส้นทาง VPN ขนส่งแพ็กเก็ต 9000 ไบต์

คุณเปิดใช้เฟรม 9000 ไบต์บน LAN และคาดว่า VPN จะเร็วขึ้น กลับช้าลง หรือหยุดส่งผ่านการถ่ายโอนขนาดใหญ่ไปเลย Jumbo frame เป็นข้อตกลงของลิงก์ท้องถิ่น ไม่ได้ขยายเส้นทางที่อุโมงค์พาดผ่าน

งบที่ใช้ได้ถูกกำหนดโดยขอบเขตที่เล็กที่สุดบนเส้นทาง รวมถึงการห่อหุ้มที่อุโมงค์เพิ่มเข้าไป

jumbo frame เปลี่ยนอะไรจริง ๆ

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

ข้อตกลงท้องถิ่น ผลกระทบระดับโลก ความสับสนทั้งหมดอยู่ตรงนี้

ภาษีของการห่อหุ้ม

อุโมงค์ห่อแพ็กเก็ตของคุณไว้ในอีกแพ็กเก็ตหนึ่ง WireGuard บน IPv4 UDP เพิ่มโอเวอร์เฮดราว 60 ไบต์ โหมด UDP ของ OpenVPN อยู่ในช่วงเดียวกัน และ IPsec แตกต่างกันไปตามโหมดและอัลกอริทึม ไบต์เหล่านั้นมาจากงบของเส้นทางชั้นนอก ไม่ใช่จากอากาศ

ดังนั้นลิงก์ชั้นนอกขนาด 1500 ไบต์จึงไม่สามารถขนส่งแพ็กเก็ตชั้นในขนาด 1500 ไบต์ได้เมื่อเพิ่มส่วนหัวของอุโมงค์เข้าไป

การคำนวณนี้คุ้มที่จะทำสักครั้ง บนเส้นทาง 1500 ไบต์ อินเทอร์เฟซ WireGuard ต้องการ MTU ราว 1420 เพื่อให้แพ็กเก็ตที่ห่อหุ้มแล้วพอดี ถ้าตั้งอินเทอร์เฟซด้านในเป็น 9000 แพ็กเก็ตขนาดใหญ่ทุกแพ็กเก็ตจะต้องแบ่งส่วนซึ่งอุโมงค์ทำไม่ได้ หรือถูกทิ้ง

หาลิงก์ที่เล็กที่สุดบนเส้นทาง

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

ICMP ที่ถูกกรองคือสาเหตุคลาสสิกที่ทำให้การถ่ายโอนขนาดใหญ่ค้างในขณะที่คำขอเล็ก ๆ ทำงานได้ดี

ทดสอบการขึ้นกับขนาดโดยไม่ขยายการเปลี่ยนแปลง

ใช้การถ่ายโอนที่เป็นตัวแทนและเก็บค่าเดิมไว้เพื่อให้ใส่กลับได้ ping -M do -s 1472 ทดสอบแพ็กเก็ตขนาด 1500 ไบต์โดยตั้งบิต DF ลดขนาดลงจนกว่าจะผ่าน ถ้าเฉพาะแพ็กเก็ตขนาดใหญ่ล้มเหลว คุณมีปัญหาเรื่องขนาด ไม่ใช่เรื่องเส้นทาง

ระวัง offload ฝั่งโฮสต์เมื่ออ่านแคปเจอร์ offload การแบ่งส่วนอาจแสดงเฟรมที่ใหญ่กว่าสิ่งที่ผ่านสายจริงมาก ทำให้เส้นทางที่ทำงานอยู่ดูเหมือนพัง และเส้นทางที่พังดูเหมือนปกติดี

เมื่อใดที่ MTU ขนาดใหญ่เป็นการออกแบบที่ถูกต้อง

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

สำหรับทางออกสาธารณะทั่วไป ให้ถือว่า 1500 หรือน้อยกว่า และปล่อยให้อุโมงค์เลือก MTU ด้านในที่ปลอดภัย RFC 8201 ครอบคลุมการค้นหา MTU ของเส้นทางสำหรับกรณี IPv6 และเป็นแหล่งอ้างอิงที่เป็นประโยชน์ว่าการตอบกลับควรทำงานอย่างไร