الخلاصة

  • قدّم Sávyo de Morais من NIC.br في 26 أكتوبر، خلال RIPE 93، أداة V6bench المفتوحة التي ما زالت في مرحلة مبكرة لاختبار التطبيقات في بيئات IPv6.
  • تبدأ من مواصفة OpenAPI فتنتج عناصر DNS وقالباً لاختبار API؛ ثم يعدّل المشغّل الخطة والمتغيرات، يشغّل السيناريوهات ويفحص ملفات CSV. نطاقها المجرب حتى الآن محدود.

نجحت الحزمة في الوصول إلى الخادم. ممتاز. هل استطاع صاحبها تسجيل الدخول وإتمام طلبه؟ هذا هو السؤال الذي حمله Sávyo de Morais إلى جلسة RIPE 93. قد تستقبل الشبكة IPv6 على الرحب، بينما يصر حارس داخل التطبيق على عنوان IPv4؛ عندها يصبح ضوء الاتصال الأخضر زينة باهظة.

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

تأخذ V6bench مواصفة OpenAPI بصيغة JSON أو YAML وتجهز مواد DNS وقالب ScanAPI. بعدها يضبط المسؤول السيناريو والمتغيرات وفق الخدمة الفعلية، يختار بيئة التشغيل، ينفذ الاختبار ويقرأ النتائج في CSV. يصف مستودع الفريق المشروع بأنه مبكر التطوير وقد تظهر فيه أخطاء، ويركز أولاً على الواجهات البرمجية. القالب المعد آلياً يشبه ورقة الامتحان المطبوعة؛ الإجابات لا تظهر لمجرد خروجها من الطابعة.

يعرض البحث عميلاً يعمل عبر IPv4 وحده أو المكدس المزدوج أو IPv6 وحده أو IPv6 مع NAT64، ويذكر SIIT-DC بين خيارات الخادم. ويتطلب المختبر جسراً لـIPv6 في Docker وأدوات مثل Kathará وJool. نجاح طلب في المكدس المزدوج يصف ذلك المسار تحديداً. يتناول مسودّة فريق عمل IETF أيضاً التوثيق والسجلات والاعتماديات ضمن اختبار التطبيق.

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

المصادر الأصلية