نجح التسجيل، وبقي مسار البيانات مغلقا

الخلاصة

• قد يكون عنوان الجهاز المتنقل صحيحا، لكنه لا ينتمي إلى نطاق المصادر المقبول عند خروجه من الشبكة التي يزورها. صحة العنوان وملاءمة موقع إرساله سؤالان مختلفان.
• يضع النفق العكسي الحزمة داخل ترويسة خارجية تناسب المسار إلى وكيل الشبكة الأصلية، مع الإبقاء على طرفي الاتصال داخل الحزمة.
• فحص القيمة 255 يقيد بعض الطلبات القادمة من خارج الوصلة، ولا يصادق على الجيران. كذلك لا يعني قبول التسجيل أن البيانات ستصل، ولا تعني إزالة التغليف أن محتواه موثوق.

نجاح في الحالة، وفشل في الطريق

في RFC 3024، يعلن الوكيل الزائر بالبت T أنه يقدم خدمة النفق العكسي، ويطلبها الجهاز المتنقل بالبت نفسه في طلب التسجيل. إذا رفض الوكيل طريقة التسليم المطلوبة، يستطيع الجهاز أن يعيد المحاولة بلا T. قد تنجح المحاولة الثانية، لكن النجاح يثبت فقط أن الوكلاء قبلوا حالة تسجيل أضعف.

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

هذا الانتقال هو الفارق الذي كشفه النفق العكسي. فقبول حالة الجهاز، وصلاحية مصدر الحزمة عند حد الشبكة، ووصول البيانات إلى الطرف المقابل ليست نتيجة واحدة. كان لا بد من غلاف خارجي يصف مرحلة الطريق الحالية، مع إبقاء عنواني الاتصال داخل الحزمة.

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

عنوان ثابت في موضع متغير

شرح RFC 2002، في أكتوبر 1996، آلية IPv4 تتيح للجهاز الاحتفاظ بعنوانه الأصلي عند الانتقال بين الشبكات الفرعية. يتولى وكيل في الشبكة الأصلية توجيه البيانات الواردة إلى عنوان يدل على موضع الوصول الحالي، يسمى care-of address.

قد يكون هذا العنوان لوكيل زائر يخدم عدة أجهزة؛ عندئذ ينهي الوكيل النفق ويسلم البيانات محليا. وقد يحصل الجهاز على عنوان مؤقت خاص به وينهي النفق بنفسه. لا يجوز دمج الحالتين والقول إن كل جهاز يستخدم وكيلا مشتركا يحتاج بالضرورة إلى عنوان IPv4 محلي منفرد.

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

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

المرشح لا يقول بالضرورة إن العنوان مسروق

تناول RFC 2827، الصادر في مايو 2000، تقييد عناوين المصدر التي يقبلها المزود من شبكة متصلة به. السماح بالبادئات المناسبة لذلك الاتصال يحد من مجال تزوير المصدر. لكنه لا يثبت هوية كل مرسل داخل النطاق المسموح، إذ قد يبقى تزوير عنوان من البادئة نفسها ممكنا.

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

أقر RFC 2827 بهذا التعارض مع Mobile IP وأشار إلى النفق العكسي. لم يكن المطلوب إلغاء فحص المصدر أو إلغاء ثبات العنوان، بل تمكين كل منهما من العمل في نطاقه. عنوان يراه الطرف المقابل بوصفه طرف الاتصال ليس مضطرا إلى أن يكون العنوان الخارجي نفسه الذي يصف مرحلة النقل الحالية.

العودة إلى الأصل داخل غلاف آخر

ظهر تعريف النفق العكسي في RFC 2344 في مايو 1998، ثم حل RFC 3024 محله. وصف «العكسي» يقارن الاتجاه بالنفق المعتاد من الوكيل الأصلي إلى الجهاز المتنقل. في الاتجاه الآخر، ترسل بيانات الجهاز أولا إلى الوكيل الأصلي، ثم تتابع نحو مراسله.

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

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

التغليف ليس تشفيرا. كما أن الاحتفاظ بعناوين الطرفين لا يعني بقاء كل بت في الحزمة الداخلية من دون تغيير؛ قد يتغير TTL أثناء إعادة التوجيه. وتماثل طرفي النفق في الاتجاهين لا يثبت أن الحزم ستسلك الوصلات الفيزيائية نفسها ذهابا وإيابا.

طريقتان، واختيار لا يجوز محوه

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

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

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

التسليم المغلف لازم أيضا لإرسال البث والبث المتعدد في الاتجاه العكسي عبر الوكيل الزائر. ليست الطريقتان مجرد اسمين لنتيجة متطابقة. إنهما تحددان ما يستطيع الجهاز اختياره وما يتعهد الوكيل بتنفيذه.

القدرة المعلنة ليست تعهدا من كل الطريق

يشير البت T في إعلان الوكيل إلى توافر خدمة النفق العكسي. ويطلبها الجهاز بوضع T في طلب التسجيل. الإعلان عن قدرة لا يساوي قبول طلب معين، وقبول الطلب لا يثبت وصول بياناته إلى التطبيق المقابل.

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

تغير نطاق الدعم الإلزامي بين النصين. كان RFC 2344 يوجب الطريقتين على الوكيل الذي يعلن خدمة النفق العكسي. أبقى RFC 3024 التسليم المباشر إلزاميا، وجعل المغلف موصى به. وأتاح الرمز 79 التعبير عن عدم دعم طريقة التسليم المطلوبة.

يؤكد سجل Mobile IP لدى IANA هذا التخصيص. بقيت في موضع من RFC 3024 ملاحظة أقدم تقول إن الرمز غير مخصص، لكن قسم التخصيصات وملحق التغييرات في الوثيقة نفسها يثبتان العكس. لا يصح تحويل الملاحظة الباقية إلى حقيقة عن السجل الحالي.

حالة مقبولة وبيانات بلا منفذ

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

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

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

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

وتحتاج قراءة عملية تحديث الارتباط إلى التصحيح التقني المعتمد لـRFC 3024: الموضع الذي ذكر رد التسجيل يجب أن يشير إلى طلب التسجيل. اتجاه الرسالة جزء من معنى الإجراء، وليس تفصيلا لغويا يمكن تبديله من دون أثر.

عنوان خاص مكرر يحتاج إلى سياق

يفترض متن RFC 3024 فضاء عناوين مشتركا، ويبحث ملحقه حالات مقيدة لفضاءات مختلفة. لا يكفي التغليف وحده لجعل كل تداخل في العناوين الخاصة قابلا للحل. يجب أن يستطيع الوكيلان الوصول أحدهما إلى الآخر في الفضاء الخارجي، وأن تكون للعناوين الداخلية دلالة مناسبة في نطاقاتها.

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

ظل RFC 5944، في نوفمبر 2010، يحيل إلى النفق العكسي عند معالجة ترشيح المصدر عند الدخول. هذه إحالة تثبت استمرار المسألة المعمارية، وليست قياسا لانتشار الاستخدام.

وقد وضع RFC 3024 حدا واضحا منذ البداية: ليس حلا عاما لعبور الجدران النارية. النفق ينظم طريقا بين أطراف محددة تحت شروط محددة. والقيمة 255، مثل عنوان المصدر المطابق، تفيد لأنها تجيب عن سؤال محدود بدقة، لا لأنها تمنح صاحب الحزمة ثقة غير محدودة.