โอเวอร์เฮดของ IPsec: โหมด NAT-T และอัลกอริทึมล้วนเปลี่ยนมัน
ตัวเลขโอเวอร์เฮดที่เผยแพร่เพียงตัวเดียวอธิบายการห่อหุ้มหนึ่งแบบบนเส้นทางหนึ่ง สรุปหัวข้อที่ทันเนลของคุณเจรจาจริง แล้ววัดเส้นทางนั้น
ที่ใดที่หนึ่งในคู่มือมีตัวเลขอยู่ตัวหนึ่ง ซึ่งมักอยู่ระหว่างหกสิบถึงแปดสิบไบต์ ที่มีคนนำไปลบออกจาก 1500 เพื่อให้ได้ MTU ของอินเทอร์เฟซ ตัวเลขนั้นอธิบายการห่อหุ้มแบบหนึ่งบนเส้นทางหนึ่ง ถ้าเปลี่ยนโหมด เปลี่ยนตระกูลที่อยู่ภายนอก เปลี่ยนการเข้ารหัส หรือเปลี่ยนว่ามี NAT หรือไม่ การคำนวณนั้นก็ใช้กับทันเนลของคุณไม่ได้อีกต่อไป
ตัวเลขนั้นมาจากทันเนลอื่น
โอเวอร์เฮดไม่ใช่คุณสมบัติของ IPsec ในเชิงนามธรรม แต่เป็นคุณสมบัติของแพ็กเก็ตที่สร้างขึ้นจริง โหมดที่เจรจาแล้ว หัวภายนอก หัวป้องกัน การเติมช่องว่าง ฟิลด์ความสมบูรณ์ และอาจมีเปลือก UDP เพิ่มอีกชั้น
ตัวเลขที่ยกมาสำหรับโหมดทรานสปอร์ตกับ IPv4 และไม่มี NAT อธิบายแพ็กเก็ตที่เล็กกว่ากว่าโหมดทันเนลกับ IPv6 ภายใต้การข้าม NAT ทั้งสองถูกต้องสำหรับกรณีของตัวเอง การคัดลอกตัวใดตัวหนึ่งไปใช้ในการติดตั้งอื่นคือวิธีที่ผู้คนลงเอยด้วย MTU ที่ทำให้การถ่ายโอนขนาดใหญ่พัง ความล้มเหลวเงียบงันเพราะคำขอเล็กยังทำงานได้
รวมชั้นที่อยู่จริงเข้าด้วยกัน
เริ่มจากหัว IP ภายนอกแล้วไล่เข้าไปข้างใน ในโหมดทันเนลแพ็กเก็ตต้นฉบับอยู่ข้างใน ดังนั้นหัวภายนอกจึงเป็นการเพิ่ม ไม่ใช่การแทนที่ RFC 4303 อธิบายหัว ESP การเติมช่องว่าง และข้อมูลความสมบูรณ์ที่ตามมา
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
ไม่มีแถวใดในนั้นที่คงที่ระหว่างการติดตั้ง และแถวการเติมช่องว่างก็ไม่คงที่แม้ภายในการติดตั้งเดียว นี่คือเหตุผลทั้งหมดที่ตัวเลขโอเวอร์เฮดที่เผยแพร่เพียงตัวเดียวทำให้ผิดหวัง
สองไซต์อาจไม่เห็นด้วยกับทันเนลเดียวกัน
แพ็กเก็ตที่ได้รับการป้องกันยังต้องข้ามเส้นทางภายนอก และเส้นทางภายนอกไม่ได้เหมือนกันทุกที่ ลิงก์เชื่อมต่อ PPPoE พาได้น้อยกว่าส่วน Ethernet ที่สะอาด เครือข่ายมือถืออาจแคบลงอีก และผู้ให้บริการที่ห่อหุ้มทราฟฟิกของตัวเองก็เพิ่มการห่อหุ้มอีกชั้นที่ไม่มีใครกล่าวถึง ทันเนลที่ทำงานบนลิงก์หนึ่งและล้มเหลวบนอีกอันกำลังอธิบายลิงก์ที่สอง ไม่ใช่โปรโตคอล
ทั้งสองทิศทางก็อาจต่างกันได้ เส้นทางที่ไม่สมมาตรอาจให้การอัปโหลดที่ทำงานและการดาวน์โหลดที่หยุดชะงัก ซึ่งอ่านได้ว่าเป็นปัญหาของแอปพลิเคชันจนกว่าจะดูขนาดแพ็กเก็ตแทนการเข้าถึง ping เล็กที่สำเร็จพิสูจน์ได้น้อยมากเกี่ยวกับการตอบกลับขนาดเต็ม
วัดแทนการลบ
หาเดตาแกรมที่ใหญ่ที่สุดที่รอดผ่านเส้นทางได้ จากนั้นเปรียบเทียบกับค่าที่อินเทอร์เฟซรายงาน
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
ลดขนาด ping ลงจนกว่าคำตอบจะมาถึง และถือค่าที่ใหญ่ที่สุดที่ทำงานได้เป็นงบประมาณของเส้นทางนั้น เอาต์พุตของ xfrm บอกว่าโหมดใดและอัลกอริทึมใดถูกเจรจา และนั่นคืออินพุตของการคำนวณที่ซื่อสัตย์ใด ๆ การดักจับยืนยันว่าบนสายมี ESP หรือ ESP ที่ห่อใน UDP ซึ่งตัดสินคำถามเรื่อง NAT โดยไม่ต้องเดา
กันค่าไว้อีกค่าหนึ่งสำหรับระนาบควบคุมด้วย แพ็กเก็ตแฮนด์เชกของ IKE มีโครงสร้างต่างจากแพ็กเก็ตข้อมูล ดังนั้นขนาดที่ได้จากการดักจับแฮนด์เชกจึงไม่ใช่ MTU ของระนาบข้อมูล
วางตัวเลขไว้ในที่ที่มันควรอยู่
สำหรับ TCP ที่ผ่านทันเนล การจำกัด MSS มักเป็นการควบคุมที่รุกล้ำน้อยที่สุด เพราะมันลดสิ่งที่ปลายทั้งสองส่งโดยไม่เปลี่ยนทันเนลเอง สำหรับทันเนลที่อิงเส้นทาง ให้ตั้ง MTU ของอินเทอร์เฟซทันเนลอย่างตั้งใจและบันทึกเหตุผลไว้ การทำทั้งสองอย่างพร้อมกันแล้ววัดภายหลังไม่ได้ให้ข้อมูลอะไรว่าอันไหนช่วย
เก็บโหมดที่เจรจา ตระกูลภายนอก สภาพของ NAT และอาการที่ทำซ้ำได้ไว้ด้วยกันในตั๋ว ชุดข้อเท็จจริงสี่ข้อที่บันทึกไว้ชนะค่าคงที่ที่จำได้ และมันเป็นเวอร์ชันเดียวของเรื่องนี้ที่อยู่รอดจากการอัปเกรดไคลเอนต์ครั้งถัดไป