الخلاصة

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

كلمة واحدة لا تصف حدود التشغيل

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

نشرت RFC 4084 في 2005 بوصفها BCP 104 لمعالجة هذا الغموض. تقترح فئات متدرجة: اتصال الويب؛ اتصال العميل بلا عنوان عام؛ اتصال العميل بعنوان عام؛ اتصال الإنترنت المحمي بجدار ناري يديره المزود؛ والاتصال الكامل. لا تقول الوثيقة إن الأوسع صالح لكل عميل، ولا تدين الخدمة الأضيق. ذكر النموذج ليس تأييداً له. القيمة في أن يعرف المشتري ما الذي يحصل عليه.

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

العنوان والوصول والإذن ثلاثة سجلات

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

لذلك يسجل الإيصال IPv4 وIPv6، وهل العنوان مشترك أم حصري، ثابت أم متغير، وكيف يُصنّف خارجياً، وDNS العكسي، ومكان الترجمة، ونطاق الدخول، والجهة التي تتحكم في الإعداد. وإذا طلب العميل جداراً نارياً مُداراً، يجب ألا يظهر كأنه قصور أصلي في الشبكة.

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

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

أربعة أعمدة تمنع الخلط

عمود المعلن يحفظ اسم المنتج ونسخته ووصفه وتاريخ العرض. عمود المتعاقد عليه يحفظ حقوق الخادم وP2P وثبات العنوان وVPN والبريد والترشيح وخيار الحماية ومسؤولية الدعم.

عمود المُعدّ يصف ما يتحكم فيه المزود: NAT، مرشحات الدخول والخروج، الوكيل، الاعتراض، DNS، ICMP، الأنفاق، تحويل البريد، والقواعد التي طلبها العميل. يحتاج كل إدخال إلى هوية تغيير.

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

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

البريد يكشف الطبقات المخفية

تذكر RFC 4084 مزودين يفرضون خادم الإرسال الخاص بهم، أو يغلقون منافذ نحو خوادم خارجية، أو يحولون المرور، أو يقيّدون POP3 وIMAP4، أو يعلنون العنوان بوصفه ديناميكياً بما يؤثر في التسليم. عمل بريد الويب لا يثبت هذه المسارات.

يفصل الإيصال بين الإرسال الموثق وSMTP الخارجي والاسترجاع البعيد ونطاق المرسل وDNS العكسي والسمعة والتحويل. وفي VPN يسجل نوع النفق والاتجاه والسكون وتغير العنوان والمسار الاحتياطي. وفي DNS يحدد حرية الوصول إلى محللات أخرى. وفي ICMP يحدد أدوات التشخيص. أما خدمات الدخول فيميز فيها بين الممنوع والمرشّح والمُعترض وغير المختبر.

للقيد طالب ومنفذ

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

الجملة المحدودة أقوى: «فشل TCP الوارد على المنفذ المحدد من شبكتين مستقلتين؛ لا توجد القاعدة في جدار العميل؛ يذكر العقد قيد المزود أو لا يذكره». هذا السجل يصلح للدعم والشراء والمراجعة، بعكس اتهام واسع لا يمكن اختباره.

المصادر