แพ็กเก็ตใหญ่หายไปบน IPsec ขณะที่ ping เล็กยังทำงาน

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

สองจุดที่แพ็กเก็ตถูกแบ่งได้

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

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

การตัดสินใจเรื่องขนาดเกิดขึ้นจริงที่ไหน

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

ตรวจค่าอินเทอร์เฟซก่อน แล้วจึงดูพฤติกรรมภายนอก ตัวเลขสองตัว สองขั้น และมักมีเพียงตัวเดียวที่รับผิดชอบ

งบประมาณภายนอกไม่ใช่งบประมาณภายใน

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

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

IPv6 ตัดทางเลือกหนึ่งออก

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

บนสแตกผสม อุโมงค์เดียวกันอาจทำงานต่างกันสำหรับสองตระกูล ดังนั้นการทดสอบครั้งเดียวบน IPv4 ไม่ได้ตัดสินข้อร้องเรียนเรื่อง IPv6 การตรวจที่ฝึกเพียงตระกูลเดียวจะทิ้งคำตอบไว้ครึ่งหนึ่งโดยไม่ได้วัด

นโยบายเซกเมนต์ TCP ไม่ใช่คำตอบทั่วไป

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

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

ลำดับการทำงาน

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

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