หลุมดำ MTU: ทำไมคำขอเล็ก ๆ ทำงานได้ แต่การอัปโหลดกลับค้าง

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

อะไรทำให้หลุมดำ

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

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

หาขนาดที่มันแตก

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

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

เพย์โหลด 1472 ไบต์ผ่านบนเส้นทาง Ethernet ที่สะอาดขนาด 1500 ไบต์เมื่อเพิ่ม 28 ไบต์ของส่วนหัว IPv4 และ ICMP เมื่อการทดสอบเดียวกันผ่านเฉพาะกับเพย์โหลดที่เล็กกว่าหลังจากอุโมงค์ขึ้นแล้ว ความแตกต่างคือโอเวอร์เฮดของการห่อหุ้ม และขอบเขตอุโมงค์คือที่ที่ข้อความปฏิเสธควรถูกสร้างขึ้น บันทึกตัวเลขทั้งสองก่อนและหลังเชื่อมต่อ เพราะคู่นั้นคือหลักฐาน ทำการทดสอบซ้ำสำหรับ IPv6 เมื่อแอปพลิเคชันใช้ เพราะส่วนหัวใหญ่กว่าและขีดจำกัดความล้มเหลวเคลื่อนที่

อ่านหลักฐานก่อนโทษอุโมงค์

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

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

ตรวจสอบการซ่อมแซมบนการขนส่งทั้งสอง

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

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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