‏DS-Lite يمنع استضافة IPv4 الواردة ولا يمنع VPN الصادر

‏DS-Lite طريقة لمنح العميل اتصال IPv4 عبر شبكة وصول لا تحمل سوى IPv6. لا يملك راوتر المنزل عنوان IPv4 عامًا مخصصًا له، وهذه الحقيقة الواحدة تُقنع الناس بأن VPN عبر IPv4 لا يمكن أن يعمل من ذلك الاتصال. في الاتجاه الصادر يعمل الأمر عادةً بلا مشكلة. يقوم المزوّد بترجمة الاتصال، ويرى الطرف البعيد عميل IPv4 عاديًا. ما يتعطّل هو الاتجاه المعاكس: استضافة شيء يتوقع IPv4 واردًا غير مطلوب. والفرق كله في أي طرف يبدأ المحادثة.

أي طرف يبدأ الاتصال

العميل الذي يبدأ الاتصال يُنشئ حالة ترجمة أثناء سيره. يرى مُترجِم المزوّد الحزمة الأولى، ويخصص تعيينًا، ثم يمرّرها. يعود المرور الراجع مطابقًا لذلك التعيين لأن التعيين موجود بالفعل.

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

تتبَّع طلبًا صادرًا

تسمّي البنية في RFC 6333 الطرفين. عنصر جهة العميل هو B4، وهو يغلّف IPv4 داخل IPv6. وعنصر جهة المزوّد هو AFTR، وهو ينفّذ ترجمة العنوان ويمرّر الحزمة بصيغة IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

يتلقى خادم VPN اتصال IPv4 عاديًا من عنوان المزوّد المترجَم. ولا يحتاج إلى وضع DS-Lite ولا إلى منفذ خاص ولا إلى أي إدراك بأن شبكة وصول العميل لا تحمل سوى IPv6. هذا هو الجزء الذي يفوته الناس: الطرف البعيد لا يستطيع أن يعرف.

إعداد العميل نفسه عادي بالقدر ذاته. يحتاج إلى مسار IPv4 عامل إلى الخادم، وهو ما يوفره B4 وAFTR، ويحتاج إلى أن يُحلّ اسم مضيف الخادم إلى عنوان IPv4.

لماذا تفشل الاستضافة الواردة

تشغيل خادم VPN بنظام IPv4 في المنزل هو التصميم الذي يصطدم بعنونة المزوّد المشتركة. فمُترجِم المزوّد يملك العنوان العام وجدول التعيين، وليس لديه سبب لإنشاء تعيين وارد دائم لمشترك واحد.

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

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

شخِّص قبل تغيير خطة الوصول

أكّد الوضع المزوَّد أولًا. المكدّس المزدوج الأصلي وDS-Lite وشبكة لا تحمل سوى IPv6 تستخدم آلية ترجمة أخرى هي ثلاثة ترتيبات مختلفة، وأسماء التسويق لدى المزوّد لا تطابق الاسم التقني دائمًا.

ثم أثبت أربع ملاحظات لفشل صادر. هل يحلّ العميل اسم مضيف VPN إلى وجهة IPv4؟ هل يعمل اتصال IPv4 المجرّد، بدلًا من طلب متصفح ربما استخدم IPv6 بهدوء؟ أي نقل وأي منفذ يحاول العميل، وهل ترى سجلات الطرف الآخر تلك المحاولة أصلًا؟ هل يحدث الفشل في التبادل الأولي، أم بعد فترة خمول، أم في عمليات النقل الأكبر فقط؟

تلك الإجابات الأربع تشير إلى التصفية أو إلى انتهاء مهلة حالة الترجمة أو إلى طرف آخر خاطئ أو إلى معالجة حجم الحزمة. ولا شيء منها يُثبت بمجرد رؤية DS-Lite في صفحة الحساب.

اقرأ تغييرات المزوّد بعناية

قد يتزامن تغيير في الحساب مع اتصال عامل بينما يغيّر عدة خصائص في وقت واحد. سجّل أي خاصية تغيّرت، لأن اسم حزمة جديد ليس تفسيرًا تقنيًا.

التعليمات بتفعيل المكدّس المزدوج تبقى غامضة حتى يؤكّد أحد ما يوفّره المزوّد فعليًا. والتعامل معها كشرط شامل لعملاء VPN عبر IPv4 يحوّل تخمينًا إلى سياسة.

إذا كان الشرط الحقيقي هو استضافة IPv4 الواردة، فناقش مع المزوّد ترتيبًا واردًا مدعومًا أو عنونة أصلية أو تصميم وصول آخر. وإذا كان الشرط حاسوبًا محمولًا يصل إلى خادم بعيد، فاسأل عن ذلك التدفّق الصادر بالتحديد. ترتيب العمل: سمِّ الاتجاه، وأكّد الوضع المزوَّد، واختبر IPv4 المجرّد ونقلًا واحدًا، ثم غيّر خطة الوصول فقط إذا كان الاتجاه يتطلب ذلك فعلًا.