ทำไมการบล็อก ICMP ทั้งหมดจึงทำให้เส้นทาง VPN ที่ทำงานอยู่เสีย
ข้อความตอบกลับเกี่ยวกับขนาดไม่ใช่การตอบ ping เมื่อมันไม่เคยมาถึง แพ็กเก็ตเล็กผ่านได้ แพ็กเก็ตใหญ่หายไป และทันเนลดูเหมือนสั่น
ทันเนลที่ผ่านการพิสูจน์ตัวตน ส่ง ping ผ่านไปได้ แล้วกลับค้างในการถ่ายโอนขนาดใหญ่ครั้งแรก เป็นสัญญาณคลาสสิกของข้อความ ICMP ที่หายไป ไม่ใช่ VPN ที่เสียหาย ผู้ส่งไม่เคยรู้ว่าแพ็กเก็ตใหญ่เกินไป จึงลองขนาดเดิมซ้ำ ๆ และแอปพลิเคชันก็รออยู่ การแก้ปัญหานี้เป็นการตัดสินใจด้านนโยบายไฟร์วอลล์ ไม่ใช่การติดตั้งไคลเอนต์ใหม่ ลำดับขั้นสำคัญ: วัดว่าขอบเขตขนาดอยู่ตรงไหน แล้วค่อยจำกัดกฎที่กลืนรายงานนั้นไป
ICMP พาข้อมูลอะไรจริง ๆ บนเส้นทางนี้
การค้นหา MTU ของเส้นทาง IPv4 อาศัยเราเตอร์ที่รายงานว่าแพ็กเก็ตที่ตั้งบิต don't-fragment ไว้ไม่สามารถส่งต่อได้ รายงานนั้นคือข้อความ ICMP Fragmentation Needed และหากไม่มีมัน ผู้ส่งก็ไม่มีเหตุผลจะลดขนาดเซกเมนต์ของตน IPv6 เข้มงวดกว่า: เราเตอร์ไม่แบ่งแพ็กเก็ตระหว่างทาง ข้อความ ICMPv6 Packet Too Big จึงเป็นสัญญาณเดียวที่ทำให้ผู้ส่งลดขนาดลง
ข้อความทั้งสองเป็นผลป้อนกลับของระนาบควบคุม และไม่มีอันใดเป็นการสะท้อนเพื่อวินิจฉัย นโยบายที่บล็อก ping กับนโยบายที่บล็อก ICMP ทั้งหมดดูคล้ายกันในรายการกฎ แต่ทำงานต่างกันมากบนเครือข่าย อย่างหลังสามารถเปลี่ยนทันเนลที่ปรับขนาดถูกต้องให้เป็นเส้นทางทางเดียวสำหรับทุกสิ่งที่ใหญ่กว่าลิงก์ที่เล็กที่สุดในห่วงโซ่
การขนส่งบางแบบค้นหาด้วยแพ็กเก็ตตรวจวัดเอง ตามที่ RFC 4821 อธิบาย และพึ่งพาผลป้อนกลับนี้น้อยกว่า นี่เป็นเหตุผลให้ตรวจสอบว่าคุณใช้การขนส่งใด ไม่ใช่สันนิษฐานว่าทุกทันเนลปลอดภัย
| ข้อความ | จุดประสงค์บนเส้นทาง | หากถูกบล็อก |
|---|---|---|
| ICMPv4 ชนิด 3 โค้ด 4 | แพ็กเก็ตใหญ่เกินไปสำหรับลิงก์ถัดไป | ผู้ส่งลองซ้ำแล้วค้าง |
| ICMPv6 ชนิด 2 | Packet Too Big ซึ่งเทียบเท่าใน IPv6 | การค้างแบบเดียวกัน โดยไม่มีทางเลือกในการแบ่งแพ็กเก็ต |
| ICMP ชนิด 11 | หมดเวลา ใช้โดย traceroute | การวินิจฉัยสูญเสียฮอป แต่ทราฟฟิกยังไหล |
| คำขอและคำตอบสะท้อน ICMP | การทดสอบการเข้าถึง | ping ล้มเหลว เส้นทางอาจปกติดี |
ความล้มเหลวขึ้นกับขนาด
ถามว่าความล้มเหลวสัมพันธ์กับขนาดแพ็กเก็ตหรือไม่ หน้าเข้าสู่ระบบ คำถาม DNS และการเรียก API สั้น ๆ ผ่านได้ ขณะที่การอัปโหลดไฟล์ การตอบกลับขนาดใหญ่ หรือการดาวน์โหลดภาพกลับค้าง รูปแบบนี้ชี้ไปที่ขีดจำกัดขนาดที่ใดที่หนึ่งระหว่างปลายทั้งสอง ไม่ใช่การพิสูจน์ตัวตนหรือการกำหนดเส้นทาง ping เล็กที่สำเร็จแทบไม่บอกอะไรว่าขอบเขตนั้นอยู่ที่ใด
ภายในทันเนลมีสองชั้นที่ต้องพิจารณา: แพ็กเก็ตเพย์โหลดและแพ็กเก็ตภายนอกที่ห่อหุ้มไว้ ผู้ส่งภายในอาจทำงานถูกต้องขณะที่เส้นทางภายนอกเล็กกว่าที่ทันเนลสันนิษฐาน จึงต้องคำนึงทั้งการตั้งค่า MTU ของทันเนลเองและลิงก์กายภาพที่อยู่ข้างใต้
วัดก่อนแก้ไขกฎ
ตรวจวัดด้วยบิต don't-fragment และขนาดเพย์โหลดที่คุณเลือกเอง จากไคลเอนต์ที่มีปัญหามุ่งไปยังที่อยู่ที่ได้รับการป้องกัน:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7เพย์โหลด 1472 ไบต์บวกส่วนหัว 28 ไบต์เป็นแพ็กเก็ต 1500 ไบต์ หากการตรวจวัดขนาดใหญ่ล้มเหลวด้วยข้อผิดพลาดการแบ่งแพ็กเก็ตและขนาดเล็กผ่านได้ คุณพบขอบเขตแล้ว ปรับตามภาระส่วนเกินของทันเนลและทำซ้ำจนขนาดที่ใช้งานได้คงที่
จากนั้นยืนยันว่าช่องว่างคือรายงานเอง หากการตรวจวัดล้มเหลวอย่างเงียบ ๆ โดยไม่มีข้อผิดพลาดและไม่มีคำตอบ ข้อความนั้นน่าจะถูกทิ้งมากกว่าถูกส่งไป และกฎคือผู้ต้องสงสัย
จำกัดกฎให้แคบลง แล้วทดสอบงานอีกครั้ง
การแก้ไขควรอนุญาตข้อความควบคุมที่เฉพาะเจาะจง ไม่ใช่ทั้งโปรโตคอล บนโฮสต์ที่ใช้ iptables รูปแบบคือการอนุญาตตามชนิด ปรับไวยากรณ์ให้เข้ากับสิ่งที่จัดการไฟร์วอลล์บนแพลตฟอร์มของคุณ:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTปล่อยให้คำตอบสะท้อนยังถูกบล็อกหากเป็นนโยบายท้องถิ่น เพราะเส้นทางไม่ได้ต้องการมัน จากนั้นทดสอบการถ่ายโอนที่ล้มเหลวแต่แรกอีกครั้งจากการเชื่อมต่อใหม่ และยืนยันว่าตัวนับของกฎแสดงว่าข้อความมาถึง
หากการถ่ายโอนขนาดใหญ่ยังค้างอยู่แม้ข้อความได้รับอนุญาตแล้ว ขีดจำกัดที่เหลืออยู่ที่อื่น: MTU ของทันเนลที่ตั้งไว้สูงเกินไป พร็อกซีที่เขียนแพ็กเก็ตใหม่ หรือกล่องกลางที่ทิ้งแทนที่จะรายงาน กฎ ICMP จำเป็นแต่ไม่เพียงพอ