ตำนาน MTU ของ VPN: ทำไมแพ็กเก็ตของคุณจึงหดเล็กลงและพื้นที่หายไปไหน

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

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

ตำนานที่หนึ่ง: MTU ของอุโมงค์คือ MTU ของเส้นทาง

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

การค้นหา MTU ของเส้นทางมีอยู่เพื่อประสานทั้งสอง และขึ้นอยู่กับผลป้อนกลับ ใน IPv4 เราเตอร์ที่ไม่สามารถส่งแพ็กเก็ตเต็มขนาดต่อได้ควรส่งข้อความ ICMP "fragmentation needed" และผู้ส่งจะลดค่าประมาณลง ใน IPv6 ตัวเทียบเท่าคือข้อความ Packet Too Big และเราเตอร์ไม่แยกส่วนระหว่างทางเลย เมื่อผลป้อนกลับนั้นถูกกรอง ผู้ส่งยังคงสร้างแพ็กเก็ตที่เส้นทางบรรทุกไม่ได้ และไม่มีอะไรบอกเขาว่าทำไม

ตำนานที่สอง: การห่อหุ้มมีค่าใช้จ่ายหนึ่งส่วนหัว

นับชั้นนอกอย่างซื่อสัตย์ ส่วนหัว IP ภายนอกคือ 20 ไบต์ใน IPv4 หรือ 40 ใน IPv6 การห่อหุ้ม UDP เพื่อผ่าน NAT เพิ่ม 8 โปรโตคอลอุโมงค์เพิ่มส่วนหัวของตัวเอง เวกเตอร์เริ่มต้นหรือ nonce การเติมจนถึงขอบบล็อกหรือการจัดแนวของรหัส ส่วนท้าย และค่าตรวจสอบความสมบูรณ์ ขึ้นอยู่กับโปรโตคอลและรหัส ยอดรวมอยู่ในหลักสิบไบต์อย่างสบายก่อนที่แพ็กเก็ตภายในจะเริ่ม

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

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

ตำนานที่สาม: PPPoE ยังให้ 1500 ที่สะอาดแก่คุณ

ลิงก์เข้าถึง PPPoE แบบปกติไม่ได้บรรทุกแพ็กเก็ต IP ขนาด 1500 ไบต์ ส่วนหัว PPPoE บวกฟิลด์โปรโตคอล PPP ใช้ 8 ไบต์ภายในเฟรม Ethernet ซึ่งเหลือ 1492 สำหรับแพ็กเก็ต IP นั่นคือขีดจำกัดดั้งเดิมที่อธิบายใน RFC 2516 หากคุณรัน VPN บนลิงก์เช่นนั้น ค่าใช้จ่ายส่วนเกินของอุโมงค์มาจาก 1492 นั้น ไม่ใช่จาก 1500

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

ทำไมความล้มเหลวจึงดูเลือกได้

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

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

จะเปลี่ยนอะไร และตามลำดับใด

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

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