แพ็กเก็ต IPv6 ใหญ่เกินไป: ทำไมการถ่ายโอน VPN ขนาดใหญ่จึงค้าง

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

คำขอเล็ก การค้างใหญ่

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

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

Packet Too Big คือผลป้อนกลับ ไม่ใช่ทราฟฟิก

ข้อความ ICMPv6 Packet Too Big พาขนาดที่ฮอปถัดไปรับได้ และผู้ส่งใช้มันเพื่อลดค่าประมาณของตน การกรองข้อความนี้เท่ากับถอดป้ายบอกทางแล้วโทษคนขับ กฎที่ทิ้ง ICMPv6 ทั้งหมดดูเข้มงวดแต่ทำลายการค้นหาเส้นทางบนทุกลิงก์ที่ต้องการมัน ข้อความเป็นข้อมูลควบคุมเกี่ยวกับเส้นทาง ไม่ใช่เพย์โหลดของแอปพลิเคชัน

การกรองแบบเลือกยังสมเหตุสมผล คำขอแบบ echo และการค้นหาเพื่อนบ้านมีบทบาทต่างจากข้อความแสดงข้อผิดพลาด และนโยบายอาจปฏิบัติต่อพวกมันต่างกัน ปฏิบัติตามคำแนะนำการกรองที่เอกสารของแพลตฟอร์มระบุ แทนที่จะรับหรือทิ้งโปรโตคอลทั้งหมด เพราะ RFC 8201 กำหนดว่าผลป้อนกลับนั้นขับเคลื่อนการค้นหาอย่างไร

ทดสอบทั้งสองตระกูลที่อยู่แยกกัน

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

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

โพรบส่งแพ็กเก็ตที่ตั้งบิต do-not-fragment และรายงานขนาดที่ล้มเหลว นั่นคือตัวเลขที่อุโมงค์ต้องรองรับ คำสั่งถามเส้นทางระบุอินเทอร์เฟซที่จะพาปลายทาง คุณจึงรู้ว่า MTU ของลิงก์ใดใช้บังคับ การดักจับกรอง ICMPv6 ชนิดที่ 2 คือข้อความ Packet Too Big และแสดงว่ามันมาถึงโฮสต์นี้หรือไม่ หากข้อความปรากฏในการดักจับแต่การถ่ายโอนยังค้าง ผู้ส่งกำลังเพิกเฉยต่อมัน ซึ่งย้ายการสอบสวนไปที่สแตกแทนที่จะเป็นเครือข่าย

ปรับขนาดอุโมงค์หลังจากมีหลักฐานเท่านั้น

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

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