OpenVPN บน PPPoE: ลด link-mtu, tun-mtu หรือ mssfix?

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

มีสามทางเลือกที่แก้ได้ และมันทำงานคนละชั้น การเลือกผิดทางอย่างหนึ่งไม่อะไรเลย หรือทำให้อุโมงค์เปราะบางในแบบใหม่ ดังนั้นการเลือกจึงเริ่มจากสิ่งที่เส้นทางรองรับจริง ๆ

สามปุ่ม สามชั้นที่ต่างกัน

link-mtu คืองบประมาณชั้นนอก: น้ำหนักที่เข้ารหัสพร้อมส่วนหัว OpenVPN ส่วนหัว UDP และส่วนหัว IP ชั้นนอก มันอธิบายสิ่งที่ออกจากเครื่อง นั่นจึงเป็นตัวเลขที่เส้นทางกายภาพจำกัด

tun-mtu คืองบประมาณชั้นใน: อินเทอร์เฟซที่ทราฟฟิกของคุณเห็น มันใหญ่กว่าสิ่งที่เส้นทางส่งได้พอดีด้วยค่าหัวอุโมงค์ และ OpenVPN ปกติจะคำนวณมันเองแทนที่จะบังคับให้คุณตั้งค่า

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

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

วัดเส้นทางก่อนเลือกตัวเลขใด ๆ

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

บนไคลเอนต์ Linux ping -M do -s 1472 ห้ามการแบ่งส่วนและล้มเหลวถ้าแพ็กเก็ตใหญ่เกินไป ลดน้ำหนักลงจนกว่าจะผ่าน แล้วเพิ่ม 28 เพื่อให้ได้ MTU ของเส้นทาง PPPoE ใช้ 8 ไบต์ ดังนั้น 1492 จึงเป็นปกติบน DSL DS-Lite และเส้นทางมือถือบางเส้นใช้ 40 หรือมากกว่า และคำตอบมักต่ำกว่าที่ความเร็วลิงก์ตามชื่อบอกไว้

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

จำกัด TCP ก่อน แล้วค่อยหดอุโมงค์

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

ลด MTU ชั้นในเมื่อทราฟฟิกที่ได้รับผลกระทบไม่ใช่ TCP บริการ UDP อุโมงค์ในอุโมงค์ หรือแอปพลิเคชันที่ส่งดาต้าแกรมเต็มขนาดจะยังล้มเหลวหลังจำกัด MSS เพราะไม่มีอะไรเขียนขนาดแพ็กเก็ตของมันใหม่ ในกรณีนั้นให้ลด tun-mtu หรือตั้ง link-mtu แล้วให้ไคลเอนต์คำนวณค่าชั้นใน แต่ห้ามทั้งสองอย่าง

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

ทำไมการทดสอบเล็ก ๆ จึงยังได้ผล

คำค้น DNS เสียงสะท้อน ICMP และการจับมือ TCP อยู่ต่ำกว่าขนาดที่ล้มเหลวมาก อุโมงค์จึงดูแข็งแรงในการทดสอบเร็วทุกครั้ง ขณะที่การจับมือ TLS และการตอบกลับ HTTP ล้มเหลวอย่างเงียบ ๆ การผสมกันนั้นเอง ทั้ง traceroute ที่ทำงานได้และเบราว์เซอร์ที่ค้างในการตอบกลับใหญ่ครั้งแรก คือสัญญาณที่ต้องมองหา เอื้อมไปหาการทดสอบเต็มขนาดก่อนเอื้อมไปหาโปรไฟล์ใหม่

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

อย่าลด MTU ชั้นในต่ำกว่า 1280 เมื่อ IPv6 วิ่งบนอุโมงค์ เพราะนั่นคือค่าต่ำสุดที่ทุกลิงก์ IPv6 ต้องส่งได้ MTU ที่เล็กกว่าเป็นข้อเท็จจริงเกี่ยวกับเส้นทาง ไม่ใช่การตั้งค่าประสิทธิภาพที่ปรับตามความรู้สึก