حزمة IPv6 كبيرة جدًا: لماذا تتوقف عمليات نقل VPN الكبيرة

يعمل ping، ويحمّل المتصفح صفحة صغيرة، ويتوقف نقل الملف، وكل ذلك عبر IPv6 من خلال النفق نفسه. يعني هذا النمط عادةً أن المرسل لم يتعلم الحجم الحقيقي للمسار، لا أن النفق بطيء. تتوقع IPv6 من الموجهات الإبلاغ عن المشكلة برسالة Packet Too Big، ويضيف التغليف حملًا إضافيًا قبل أن تصل الحزمة إلى الشبكة الخارجية. وإذا تمت تصفية تلك الرسالة، يظل المرسل يكرر حجمًا لا يمكن أن يمر.

طلبات صغيرة وتوقفات كبيرة

يلف النفق كل حزمة في ترويسة أخرى، لذلك يكون الحجم القابل للاستخدام في الداخل أصغر من الحجم في الخارج. الحزمة التي تم ضبط حجمها للوصلة الفيزيائية قبل التغليف تصبح كبيرة جدًا بعد ذلك. قد تقوم موجهات IPv4 بالتجزئة على المسار، بينما لا تفعل موجهات IPv6 ذلك نيابةً عن المرسل، لذا على المرسل أن يتكيف بدلًا من ذلك. ويعتمد هذا التكيف كليًا على استقبال التغذية الراجعة.

رسالة واحدة مفقودة تكفي لإنتاج العرض الكلاسيكي: تنجح المصافحات والردود الصغيرة، وتتعطل قائمة الدليل أو عملية الرفع عند النقطة نفسها في كل مرة. يصف المستخدمون الأمر بأن VPN بطيء، ولا تُظهر السجلات أي خلل في المصادقة. الملاحظتان دقيقتان، ولا واحدة منهما تحدد العطل.

رسالة Packet Too Big تغذية راجعة وليست حركة مرور

تحمل رسالة ICMPv6 Packet Too Big الحجم الذي يمكن للقفزة التالية قبوله، ويستخدمها المرسل لخفض تقديره. تصفيتها تعادل إزالة لافتة طريق ثم لوم السائقين. تبدو القاعدة التي تُسقط كل ICMPv6 صارمة بينما تعطل اكتشاف المسار على كل وصلة تحتاج إليه. الرسالة معلومة تحكم عن المسار، وليست حمولة تطبيق.

تظل التصفية الانتقائية معقولة. تلعب طلبات الصدى واكتشاف الجيران أدوارًا مختلفة عن رسائل الخطأ، ويمكن للسياسة أن تعاملها بشكل مختلف. اتبع إرشادات التصفية الموثقة في المنصة بدلًا من قبول البروتوكول بأكمله أو إسقاطه، لأن 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'

يرسل الفحص حزمة مع ضبط بت عدم التجزئة ويبلغ عن الحجم الذي يفشل عنده، وهو الرقم الذي يجب أن يستوعبه النفق. يحدد استعلام المسار الواجهة التي ستحمل الوجهة، لتعرف أي MTU للوصلة ينطبق. وترشح عملية الالتقاط رسائل ICMPv6 من النوع 2، أي رسالة Packet Too Big، وتُظهر ما إذا كانت تصل إلى هذا المضيف أصلًا. وإذا ظهرت الرسالة في الالتقاط وظل النقل متعطلًا، فالمرسل يتجاهلها، ما ينقل التحقيق إلى المكدس بدلًا من الشبكة.

اضبط حجم النفق بعد الأدلة فقط

إن خفض MTU للنفق قد يخفي رسالة مُصفّاة ويجعل العرض يختفي، مقابل حمل إضافي أكبر على كل حزمة. هذا حل مؤقت وليس تشخيصًا، وينبغي أن يتبع الالتقاط بدلًا من أن يحل محله. كما أن القيمة المنخفضة العشوائية لا تكسر شيئًا ظاهريًا، ولهذا تبقى في الإعدادات سنوات. غيّرها بقرار، وسجّل القيمة، ودوّن القياس الذي بررها.

عندما تتحكم بالبوابة، افحص القاعدة التي تُسقط الرسالة بدلًا من تعطيل جدار الحماية. قاعدة واحدة مصححة أضيق من استثناء في السياسة وأسهل بكثير في الدفاع عنها لاحقًا. وينطبق المنطق نفسه على المهلات: ليس كل تعطل مشكلة حجم، والالتقاط هو ما يفصل بينهما.