تم إنشاء هذه الترجمة باستخدام التعلم الآلي وقد لا تكون دقيقة بنسبة 100%. عرض النسخة الإنجليزية

توجيه Tunnel

نظرة عامة على مصطلحات وبناء وتشغيل tunnel في I2P

نظرة عامة

تحتوي هذه الصفحة على نظرة عامة حول مصطلحات وتشغيل tunnel في I2P، مع روابط لصفحات تقنية أكثر تفصيلاً ومواصفات.

كما هو موضح بإيجاز في المقدمة ، ينشئ I2P “أنفاق” افتراضية - مسارات مؤقتة وأحادية الاتجاه عبر سلسلة من أجهزة router. تصنف هذه الأنفاق إما كأنفاق واردة (حيث كل شيء يُعطى لها يذهب نحو منشئ النفق) أو أنفاق صادرة (حيث منشئ النفق يدفع الرسائل بعيداً عنه). عندما تريد Alice إرسال رسالة إلى Bob، ستقوم (عادة) بإرسالها عبر أحد أنفاقها الصادرة الموجودة مع تعليمات لنقطة نهاية ذلك النفق لتوجيهها إلى router البوابة لأحد أنفاق Bob الواردة الحالية، والذي بدوره يمررها إلى Bob.

أليس تتصل عبر tunnel الصادر الخاص بها إلى بوب عبر tunnel الوارد الخاص به

A: Outbound Gateway (Alice)
B: Outbound Participant
C: Outbound Endpoint
D: Inbound Gateway
E: Inbound Participant
F: Inbound Endpoint (Bob)

مصطلحات Tunnel

  • بوابة tunnel - أول router في tunnel. بالنسبة لـ tunnels الواردة، هذا هو المذكور في LeaseSet المنشور في قاعدة بيانات الشبكة . بالنسبة لـ tunnels الصادرة، البوابة هي router المنشئ. (مثل كل من A و D أعلاه)

  • نقطة نهاية النفق - آخر router في النفق. (مثل C و F أعلاه)

  • مشارك في tunnel - جميع أجهزة router في tunnel باستثناء البوابة أو نقطة النهاية (مثل كل من B و E أعلاه)

  • n-Hop tunnel - tunnel بعدد محدد من القفزات بين أجهزة router، مثل:

    • 0-hop tunnel - tunnel حيث البوابة هي أيضاً نقطة النهاية
    • 1-hop tunnel - tunnel حيث البوابة تتحدث مباشرة مع نقطة النهاية
    • 2-(أو أكثر)-hop tunnel - tunnel حيث يوجد على الأقل مشارك tunnel وسيط واحد. (الرسم البياني أعلاه يتضمن اثنين من 2-hop tunnels - واحد صادر من Alice، وواحد وارد إلى Bob)
  • Tunnel ID - عدد صحيح من 4 بايت مختلف لكل قفزة في tunnel، وفريد بين جميع tunnels على router. يتم اختياره عشوائياً بواسطة منشئ tunnel.


معلومات بناء Tunnel

يتم إعطاء أجهزة router التي تؤدي الأدوار الثلاثة (البوابة، المشارك، نقطة النهاية) قطع بيانات مختلفة في رسالة بناء النفق الأولية لإنجاز مهامها:

tunnel gateway يحصل على:

  • مفتاح تشفير tunnel - مفتاح AES خاص لتشفير الرسائل والتعليمات للقفزة التالية
  • مفتاح IV الخاص بـ tunnel - مفتاح AES خاص للتشفير المزدوج لـ IV للقفزة التالية
  • مفتاح الرد - مفتاح AES عام لتشفير الرد على طلب بناء tunnel
  • IV الرد - IV لتشفير الرد على طلب بناء tunnel
  • معرف tunnel - عدد صحيح 4 بايت (البوابات الواردة فقط)
  • القفزة التالية - أي router هو التالي في المسار (إلا إذا كان هذا tunnel من 0-قفزة، والبوابة هي أيضاً نقطة النهاية)
  • معرف tunnel التالي - معرف tunnel على القفزة التالية

جميع المشاركين الوسطاء في tunnel يحصلون على:

  • مفتاح تشفير tunnel - مفتاح AES خاص لتشفير الرسائل والتعليمات إلى القفزة التالية
  • مفتاح IV الخاص بـ tunnel - مفتاح AES خاص للتشفير المزدوج لـ IV إلى القفزة التالية
  • مفتاح الرد - مفتاح AES عام لتشفير الرد على طلب بناء tunnel
  • IV الرد - IV لتشفير الرد على طلب بناء tunnel
  • معرف tunnel - عدد صحيح من 4 بايت
  • القفزة التالية - ما هو router التالي في المسار
  • معرف tunnel التالي - معرف tunnel في القفزة التالية

نقطة نهاية tunnel تحصل على:

  • مفتاح تشفير tunnel - مفتاح AES خاص لتشفير الرسائل والتعليمات إلى نقطة النهاية (نفسها)
  • مفتاح IV للtunnel - مفتاح AES خاص للتشفير المزدوج لـ IV إلى نقطة النهاية (نفسها)
  • مفتاح الرد - مفتاح AES عام لتشفير الرد على طلب بناء tunnel (نقاط النهاية الصادرة فقط)
  • IV الرد - IV لتشفير الرد على طلب بناء tunnel (نقاط النهاية الصادرة فقط)
  • معرف tunnel - عدد صحيح 4 بايت (نقاط النهاية الصادرة فقط)
  • router الرد - البوابة الواردة للtunnel لإرسال الرد من خلالها (نقاط النهاية الصادرة فقط)
  • معرف tunnel للرد - معرف tunnel الخاص بـ router الرد (نقاط النهاية الصادرة فقط)

التفاصيل موجودة في مواصفات إنشاء الأنفاق .


تجميع الأنفاق

يمكن تجميع عدة tunnels لغرض معين في “مجموعة tunnel”، كما هو موضح في مواصفات tunnel . هذا يوفر التكرار وعرض النطاق الترددي الإضافي. المجموعات المستخدمة من قبل router نفسه تسمى “exploratory tunnels”. المجموعات المستخدمة من قبل التطبيقات تسمى “client tunnels”.


طول Tunnel

كما ذُكر أعلاه، يطلب كل عميل من router الخاص به توفير tunnels تتضمن على الأقل عددًا معينًا من القفزات. إن القرار حول عدد routers التي يجب أن تكون في tunnels الصادرة والواردة له تأثير مهم على زمن الاستجابة والإنتاجية والموثوقية وإخفاء الهوية التي يوفرها I2P - فكلما زاد عدد النظراء التي يجب أن تمر بها الرسائل، كلما استغرق الوصول وقتًا أطول وزادت احتمالية فشل أحد هذه routers بشكل مبكر. وكلما قل عدد routers في tunnel، كلما أصبح من الأسهل على المهاجم شن هجمات تحليل حركة البيانات واختراق إخفاء هوية شخص ما. يتم تحديد أطوال tunnel من قبل العملاء عبر خيارات I2CP . العدد الأقصى للقفزات في tunnel هو 7.

tunnels صفر قفزة

مع عدم وجود routers بعيدة في tunnel، يحصل المستخدم على إنكار معقول أساسي جداً (حيث لا أحد يعلم بالتأكيد أن النظير الذي أرسل إليهم الرسالة لم يكن ببساطة يقوم بإعادة توجيهها كجزء من tunnel). ومع ذلك، سيكون من السهل إلى حد ما شن هجوم تحليل إحصائي وملاحظة أن الرسائل المستهدفة لوجهة محددة يتم إرسالها دائماً عبر بوابة واحدة. التحليل الإحصائي ضد tunnels الصادرة من نوع 0-hop أكثر تعقيداً، لكن يمكن أن يظهر معلومات مماثلة (رغم أنه سيكون أصعب قليلاً في التنفيذ).

tunnels أحادية القفزة

مع وجود router واحد بعيد فقط في tunnel، يحصل المستخدم على إنكار معقول وإخفاء هوية أساسي، طالما أنهم لا يواجهون خصماً داخلياً (كما هو موضح في نموذج التهديد ). ومع ذلك، إذا قام الخصم بتشغيل عدد كافٍ من routers بحيث يكون router البعيد الوحيد في tunnel غالباً واحداً من تلك routers المخترقة، فسيكون قادراً على شن هجوم التحليل الإحصائي لحركة البيانات المذكور أعلاه.

أنفاق بقفزتين

مع وجود اثنين أو أكثر من الـ routers البعيدة في نفق واحد، تزداد تكاليف شن هجوم تحليل حركة المرور، حيث يجب اختراق العديد من الـ routers البعيدة لتنفيذه.

أنفاق ثلاثية القفزات (أو أكثر)

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

أطوال tunnel الافتراضية

يستخدم router نفق من قفزتين افتراضياً لأنفاق الاستكشاف الخاصة به. يتم تعيين إعدادات tunnel العميل الافتراضية بواسطة التطبيق، باستخدام خيارات I2CP . معظم التطبيقات تستخدم قفزتين أو 3 قفزات كإعداد افتراضي.


اختبار الـ Tunnel

يتم اختبار جميع الأنفاق بشكل دوري من قبل منشئها عن طريق إرسال DeliveryStatusMessage عبر tunnel صادر ومتجه إلى tunnel وارد آخر (اختبار كلا النفقين في آن واحد). إذا فشل أي منهما في عدد متتالي من الاختبارات، يتم وسمه كغير فعال. إذا كان يُستخدم لـ tunnel وارد للعميل، يتم إنشاء leaseSet جديد. تنعكس إخفاقات اختبار الأنفاق أيضاً في تقييم السعة في ملف تعريف النظير .


إنشاء Tunnel

يتم التعامل مع إنشاء tunnel من خلال garlic routing وهو Tunnel Build Message إلى router، مطالباً إياه بالمشاركة في tunnel (مع توفير جميع المعلومات المناسبة، كما هو مذكور أعلاه، إلى جانب شهادة، والتي هي حالياً شهادة ’null’، ولكنها ستدعم hashcash أو شهادات أخرى غير مجانية عند الضرورة). يقوم ذلك router بإعادة توجيه الرسالة إلى القفزة التالية في tunnel. التفاصيل موجودة في مواصفات إنشاء tunnel .


تشفير الـ tunnel

يتم التعامل مع التشفير متعدد الطبقات من خلال garlic encryption لرسائل tunnel. التفاصيل موجودة في مواصفات tunnel . يتم تشفير IV الخاص بكل hop بمفتاح منفصل كما هو موضح هناك.


العمل المستقبلي

  • يمكن استخدام تقنيات أخرى لاختبار الأنفاق، مثل تغليف garlic لعدد من الاختبارات في cloves، واختبار المشاركين الفرديين في النفق بشكل منفصل، إلخ.

  • الانتقال إلى إعدادات tunnels الاستكشافية افتراضية بـ 3 قفزات.

  • في إصدار مستقبلي بعيد، قد يتم تنفيذ خيارات تحدد إعدادات التجميع والخلط وتوليد البيانات الوهمية.

  • في إصدار مستقبلي بعيد، قد يتم تطبيق قيود على كمية وحجم الرسائل المسموح بها خلال فترة حياة tunnel (مثل عدم أكثر من 300 رسالة أو 1 ميجابايت في الدقيقة).


انظر أيضًا

Was this page helpful?