نظرة عامة
يحدد هذا الاقتراح تصميم بروتوكول يمكّن عميل I2P أو خدمة أو عملية موازنة خارجية من إدارة عدة موجهات (routers) تستضيف بشكل شفاف وجهة واحدة Destination .
حاليًا لا يحدد هذا الاقتراح تنفيذًا ملموسًا. يمكن تنفيذه كامتداد لـ I2CP ، أو كبروتوكول جديد.
الدوافع
“المُضيف المتعدد” (Multihoming) هو استخدام عدة موجهات لاستضافة نفس الوجهة. الطريقة الحالية لتحقيق المُضيف المتعدد في I2P هي تشغيل نفس الوجهة على كل موجه بشكل مستقل؛ والموجه الذي يستخدمه العملاء في أي وقت معين هو آخر موجه نشر مجموعة تأجير (LeaseSet).
هذا حل مؤقت، ومن المرجح ألا يعمل بشكل جيد للمواقع الكبيرة على نطاق واسع. لنفترض أن لدينا 100 موجه متعدد المضيفين، ولكل موجه 16 نفقًا. هذا يعني 1600 عملية نشر لمجموعة التأجير كل 10 دقائق، أي ما يقارب 3 عمليات في الثانية. ستُثقل خوادم الفيض (floodfills) وستُفعّل آليات التقييد (throttles). وهذا قبل أن نذكر حتى حركة البحث (lookup traffic).
يحل الاقتراح 123 هذه المشكلة باستخدام “مجموعة تأجير فائقة” (meta-LeaseSet)، تسرد 100 تجزئة حقيقية لمجموعة التأجير. تصبح عملية البحث عملية من مرحلتين: أولًا البحث عن مجموعة التأجير الفائقة، ثم واحدة من مجموعات التأجير المسماة. هذا حل جيد لمشكلة حركة البحث، لكنه وحده يخلق تسريبًا كبيرًا للخصوصية: من الممكن تحديد أي الموجهات المتعددة المُضيفة متصلة بالشبكة من خلال مراقبة مجموعة التأجير الفائقة المنشورة، لأن كل مجموعة تأجير حقيقية تتوافق مع موجه واحد فقط.
نحتاج إلى طريقة تمكن عميل I2P أو خدمة من توزيع وجهة واحدة عبر عدة موجهات، بطريقة لا يمكن التمييز بينها وبين استخدام موجه واحد (من منظور مجموعة التأجير نفسها).
التصميم
التعريفات
المستخدم
الشخص أو المؤسسة التي ترغب في استخدام المُضيف المتعدد لوجهاتها. تُعتبر وجهة واحدة هنا دون فقدان العمومية (WLOG).
العميل
التطبيق أو الخدمة التي تعمل خلف الوجهة. قد يكون تطبيقًا من جانب العميل أو الخادم أو من ند إلى ند؛ نشير إليه على أنه عميل بمعنى أنه يتصل بموجهات I2P.
يتكون العميل من ثلاثة أجزاء، قد تكون جميعها في نفس العملية أو قد تُقسم عبر عمليات أو أجهزة (في إعداد متعدد العملاء):
الموازن (Balancer)
الجزء من العميل الذي يدير اختيار الأقران وبناء الأنفاق. يوجد موازن واحد في كل مرة، ويتواصل مع جميع موجهات I2P. قد توجد موازنات احتياطية (failover).
الواجهة الأمامية (Frontend)
الجزء من العميل الذي يمكن تشغيله بشكل متوازٍ. تتواصل كل واجهة أمامية مع موجه I2P واحد فقط.
الواجهة الخلفية (Backend)
الجزء من العميل الذي يُشترك فيه جميع الواجهات الأمامية. لا يتواصل مباشرة مع أي موجه I2P.
الموجه (Router)
موجه I2P يشغله المستخدم ويقع عند الحدود بين شبكة I2P وشبكة المستخدم (مثل جهاز حافة في الشبكات المؤسسية). يبني الأنفاق بناءً على أوامر من الموازن، ويرشّد الحزم للعميل أو الواجهة الأمامية.
نظرة عامة عامة
تخيل التكوين المطلوب التالي:
- تطبيق عميل بوجهة واحدة.
- أربعة موجهات، يدير كل منها ثلاثة أنفاق داخلة.
- يجب نشر جميع الأنفاق الاثني عشر في مجموعة تأجير واحدة.
عميل واحد
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \
| \
|-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ /
| /
|-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/
عميل متعدد
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]---------[Frontend 1]
|-{ [Tunnel 3]===/ \ \
| \ \
|-{ [Tunnel 4]===\ \ \
[Destination] |-{ [Tunnel 5]====[Router 2]---\-----[Frontend 2] \
\ |-{ [Tunnel 6]===/ \ \ \ \
[LeaseSet]--| [Balancer] [Backend]
|-{ [Tunnel 7]===\ / / / /
|-{ [Tunnel 8]====[Router 3]---/-----[Frontend 3] /
|-{ [Tunnel 9]===/ / /
| / /
|-{ [Tunnel 10]==\ / /
|-{ [Tunnel 11]===[Router 4]---------[Frontend 4]
-{ [Tunnel 12]==/
عملية العميل العامة
تحميل أو توليد وجهة.
فتح جلسة مع كل موجه، مرتبطة بالوجهة.
بشكل دوري (حوالي كل عشر دقائق، ولكن أكثر أو أقل حسب حياة النفق):
الحصول على الطبقة السريعة (fast tier) من كل موجه.
استخدام مجموعة الأقران الفائقة لبناء أنفاق من وإلى كل موجه.
- بشكل افتراضي، ستستخدم الأنفاق من/إلى موجه معين أقرانًا من الطبقة السريعة لذلك الموجه، لكن البروتوكول لا يفرض ذلك.
جمع مجموعة الأنفاق الداخلة النشطة من جميع الموجهات النشطة، وإنشاء مجموعة تأجير.
نشر مجموعة التأجير عبر واحد أو أكثر من الموجهات.
الاختلافات عن I2CP
لإنشاء وإدارة هذا التكوين، يحتاج العميل إلى الوظائف الجديدة التالية التي تتجاوز ما يوفره حاليًا I2CP :
- إخبار الموجه ببناء أنفاق، دون إنشاء مجموعة تأجير لها.
- الحصول على قائمة بالأنفاق الحالية في مجموعة الأنفاق الداخلة.
بالإضافة إلى ذلك، تتيح الوظائف التالية مرونة كبيرة في كيفية إدارة العميل لأنفاقه:
- الحصول على محتويات الطبقة السريعة لموجه.
- إخبار الموجه ببناء نفق داخلي أو خارجي باستخدام قائمة معينة من الأقران.
مخطط البروتوكول
Client Router
---------------------> Create Session
Session Status <---------------------
---------------------> Get Fast Tier
Peer List <---------------------
---------------------> Create Tunnel
Tunnel Status <---------------------
---------------------> Get Tunnel Pool
Tunnel List <---------------------
---------------------> Publish LeaseSet
---------------------> Send Packet
Send Status <---------------------
Packet Received <---------------------
الرسائل
Create Session
- إنشاء جلسة للوجهة المحددة.
Session Status
- تأكيد أن الجلسة قد تم إعدادها، ويمكن للعميل الآن بدء بناء الأنفاق.
Get Fast Tier
- طلب قائمة بالأقران التي يعتبرها الموجه حاليًا مناسبة لبناء أنفاق من خلالها.
Peer List
- قائمة بالأقران المعروفة للموجه.
Create Tunnel
- طلب من الموجه بناء نفق جديد عبر الأقران المحددة.
Tunnel Status
- نتيجة بناء نفق معين، عند توفرها.
Get Tunnel Pool
- طلب قائمة بالأنفاق الحالية في مجموعة الأنفاق الداخلة أو الخارجة للوجهة.
Tunnel List
- قائمة بالأنفاق لمجموعة الأنفاق المطلوبة.
Publish LeaseSet
- طلب من الموجه نشر مجموعة التأجير المقدمة عبر أحد الأنفاق الخارجة للوجهة. لا حاجة لرد الحالة؛ يجب على الموجه الاستمرار في إعادة المحاولة حتى يتأكد من نشر مجموعة التأجير.
Send Packet
- حزمة صادرة من العميل. يمكن تحديد نفق خارجي يجب (أو ينبغي؟) إرسال الحزمة من خلاله.
Send Status
- إبلاغ العميل بنجاح أو فشل إرسال حزمة.
Packet Received
- حزمة واردة للعميل. يمكن تحديد النفق الداخلي الذي استُلمت من خلاله الحزمة (?)
الآثار الأمنية
من منظور الموجهات، هذا التصميم مكافئ وظيفيًا للوضع الحالي. لا يزال الموجه يبني جميع الأنفاق، ويحافظ على ملفاته الشخصية للأقران، ويفصل بين عمليات الموجه والعميل. في التكوين الافتراضي يكون مطابقًا تمامًا، لأن الأنفاق لهذا الموجه تُبنى من طبقته السريعة الخاصة.
من منظور قاعدة بيانات الشبكة (netDB)، تكون مجموعة تأجير واحدة تم إنشاؤها عبر هذا البروتوكول مطابقة للوضع الحالي، لأنها تعتمد على وظائف موجودة مسبقًا. ومع ذلك، بالنسبة لمجموعات التأجير الكبيرة التي تقترب من 16 تأجيرًا، قد يكون من الممكن لمراقب تحديد أن مجموعة التأجير متعددة المضيفين:
الحد الأقصى الحالي لحجم الطبقة السريعة هو 75 قرينًا. يتم اختيار بوابة الدخول الداخلة (IBGW، العقدة المنشورة في التأجير) من جزء من هذه الطبقة (مقسّم عشوائيًا لكل مجموعة أنفاق حسب الهاش، وليس العدد):
1 قفزة الطبقة السريعة بأكملها 2 قفزات نصف الطبقة السريعة (الافتراضي حتى منتصف 2014) 3+ قفزات ربع الطبقة السريعة (3 هي القيمة الافتراضية الحالية)هذا يعني أن IBGWs ستكون في المتوسط من مجموعة تتكون من 20 إلى 30 قرينًا.
في إعداد مُضيف واحد، ستكون مجموعة التأجير الكاملة المكونة من 16 نفقًا لديها 16 IBGWs مختارة عشوائيًا من مجموعة تصل إلى (نقول) 20 قرينًا.
في إعداد مُضيف متعدد بـ 4 موجهات باستخدام التكوين الافتراضي، ستكون مجموعة التأجير الكاملة المكونة من 16 نفقًا لديها 16 IBGWs مختارة عشوائيًا من مجموعة لا تزيد عن 80 قرينًا، على الرغم من وجود احتمال لوجود عدد من الأقران المشتركين بين الموجهات.
وبالتالي، من الممكن باستخدام التحليل الإحصائي تحديد أن مجموعة التأجير تم إنشاؤها بواسطة هذا البروتوكول. قد يكون من الممكن أيضًا تحديد عدد الموجهات، على الرغم من أن تأثير التغير (churn) على الطبقات السريعة سيقلل من فعالية هذا التحليل.
بما أن العميل لديه تحكم كامل في الأقران الذين يختارهم، يمكن تقليل أو إزالة تسريب المعلومات هذا من خلال اختيار IBGWs من مجموعة محدودة من الأقران.
التوافق
هذا التصميم متوافق تمامًا مع الشبكة، لأنه لا توجد تغييرات على تنسيق مجموعة التأجير. ستحتاج جميع الموجهات إلى معرفة البروتوكول الجديد، لكن هذا ليس مصدر قلق لأنها ستكون جميعها تحت سيطرة الكيان نفسه.
ملاحظات حول الأداء والقابلية للتوسع
الحد الأقصى البالغ 16 تأجيرًا لكل مجموعة تأجير لا يتغير بسبب هذا الاقتراح. بالنسبة للوجهات التي تتطلب أنفاقًا أكثر من ذلك، هناك تعديلان شبكيان محتملان:
زيادة الحد الأقصى لحجم مجموعات التأجير. سيكون هذا أبسط تنفيذًا (رغم أنه سيتطلب دعمًا شبكيًا واسع الانتشار قبل أن يمكن استخدامه على نطاق واسع)، لكنه قد يؤدي إلى عمليات بحث أبطأ بسبب أحجام الحزم الأكبر. ويُعرّف الحد الأقصى الممكن لمجموعة التأجير بـ MTU للنقل الأساسي، وبالتالي يكون حوالي 16 كيلوبايت.
تنفيذ الاقتراح 123 لمجموعات التأجير الطبقية. بالاقتران مع هذا الاقتراح، يمكن توزيع الوجهات الخاصة بمجموعات التأجير الفرعية عبر عدة موجهات، مما يعمل بشكل فعّال كعناوين IP متعددة لخدمة الشبكة الواضحة (clearnet).
الشكر والتقدير
شكرًا لـ psi على المناقشة التي أدت إلى هذا الاقتراح.