تنفيذ Tunnel | I2P - مشروع الإنترنت غير المرئي

تُوثق هذه الصفحة تطبيق tunnel الحالي.

نظرة عامة على Tunnel

داخل I2P، يتم تمرير الرسائل في اتجاه واحد عبر tunnel افتراضي من الأقران، باستخدام أي وسائل متاحة لتمرير الرسالة إلى القفزة التالية. تصل الرسائل إلى gateway الخاص بـ tunnel، حيث يتم تجميعها و/أو تقسيمها إلى رسائل tunnel بحجم ثابت، ثم يتم إرسالها إلى القفزة التالية في tunnel، والتي تقوم بمعالجة والتحقق من صحة الرسالة وإرسالها إلى القفزة التالية، وهكذا، حتى تصل إلى نقطة نهاية tunnel. تأخذ تلك النقطة النهائية الرسائل التي تم تجميعها بواسطة gateway وتقوم بإرسالها وفقاً للتعليمات - إما إلى router آخر، أو إلى tunnel آخر على router آخر، أو محلياً.

تعمل جميع الـ tunnels بنفس الطريقة، ولكن يمكن تقسيمها إلى مجموعتين مختلفتين - inbound tunnels و outbound tunnels. الـ inbound tunnels لها gateway غير موثوق يمرر الرسائل نحو الأسفل إلى منشئ الـ tunnel، والذي يعمل كنقطة نهاية الـ tunnel. بالنسبة للـ outbound tunnels، يعمل منشئ الـ tunnel كـ gateway، ويمرر الرسائل إلى نقطة النهاية البعيدة.

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

في الممارسة العملية، يتم استخدام سلسلة من مجمعات tunnel لأغراض مختلفة - كل وجهة عميل محلية لديها مجموعتها الخاصة من tunnel الواردة وtunnel الصادرة، مُهيأة لتلبية احتياجاتها من إخفاء الهوية والأداء. بالإضافة إلى ذلك، يحتفظ الrouter نفسه بسلسلة من المجمعات للمشاركة في netDb وإدارة tunnel أنفسها.

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

نظرة عامة على مصطلحات tunnel في I2P متوفرة في صفحة نظرة عامة على tunnel .

عملية Tunnel (معالجة الرسائل)

نظرة عامة

بعد بناء النفق، يتم معالجة رسائل I2NP وتمريرها من خلاله. تشغيل النفق له أربع عمليات متميزة، يقوم بها أقران مختلفون في النفق.

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

المشاركون الوسطاء في tunnel لا يعرفون ما إذا كانوا في tunnel وارد أم صادر؛ فهم دائماً “يشفرون” للقفزة التالية. لذلك، نستفيد من التشفير المتماثل AES “لفك التشفير” عند بوابة tunnel الصادر، بحيث يتم الكشف عن النص الواضح في نقطة النهاية الصادرة.

Role	Preprocessing	Encryption Operation	Postprocessing
Outbound Gateway (Creator)	Fragment, Batch, and Pad	Iteratively encrypt (using decryption operations)	Forward to next hop
Participant		Decrypt (using an encryption operation)	Forward to next hop
Outbound Endpoint		Decrypt (using an encryption operation) to reveal plaintext tunnel message	Reassemble Fragments, Forward as instructed to Inbound Gateway or Router

Inbound Gateway	Fragment, Batch, and Pad	Encrypt	Forward to next hop
Participant		Encrypt	Forward to next hop
Inbound Endpoint (Creator)		Iteratively decrypt to reveal plaintext tunnel message	Reassemble Fragments, Receive data

### معالجة البوابة {#tunnel.gateway}

معالجة الرسائل المسبقة

وظيفة بوابة tunnel هي تجزئة وتعبئة رسائل I2NP في رسائل tunnel ذات حجم ثابت وتشفير رسائل tunnel. رسائل tunnel تحتوي على ما يلي:

معرف نفق مكون من 4 بايت
متجه تهيئة IV مكون من 16 بايت
مجموع تحقق
حشو، إذا لزم الأمر
زوج أو أكثر من { تعليمة التسليم، جزء رسالة I2NP }

معرفات tunnel هي أرقام مكونة من 4 بايت تُستخدم في كل قفزة - المشاركون يعرفون معرف tunnel الذي يجب الاستماع إليه للرسائل ومعرف tunnel الذي يجب توجيه الرسائل عليه إلى القفزة التالية، وكل قفزة تختار معرف tunnel الذي تستقبل الرسائل عليه. tunnels نفسها قصيرة المدى (10 دقائق). حتى لو تم بناء tunnels لاحقة باستخدام نفس تسلسل الأقران، فإن معرف tunnel لكل قفزة سيتغير.

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

التفاصيل موجودة في مواصفات رسائل tunnel .

تشفير البوابة

بعد المعالجة المسبقة للرسائل إلى حمولة مبطنة، يقوم الـ gateway ببناء قيمة IV عشوائية من 16 بايت، ويقوم بتشفيرها بشكل تكراري مع رسالة الـ tunnel حسب الحاجة، ويُرسل المجموعة {tunnelID, IV, encrypted tunnel message} إلى القفزة التالية.

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

معالجة المشارك

عندما يتلقى peer رسالة tunnel، فإنه يتحقق من أن الرسالة جاءت من نفس القفزة السابقة كما من قبل (تتم تهيئتها عندما تمر الرسالة الأولى عبر tunnel). إذا كان الـ peer السابق هو router مختلف، أو إذا تم رؤية الرسالة من قبل، يتم إسقاط الرسالة. يقوم المشارك بعدها بتشفير الـ IV المستلم باستخدام AES256/ECB مع مفتاح الـ IV الخاص به لتحديد الـ IV الحالي، ويستخدم ذلك الـ IV مع مفتاح طبقة المشارك لتشفير البيانات، ويشفر الـ IV الحالي باستخدام AES256/ECB مع مفتاح الـ IV الخاص به مرة أخرى، ثم يُحوِّل الثلاثية {nextTunnelId, nextIV, encryptedData} إلى القفزة التالية. هذا التشفير المزدوج لـ IV (قبل الاستخدام وبعده) يساعد في التصدي لفئة معينة من هجمات التأكيد.

يتم التعامل مع كشف الرسائل المكررة بواسطة مرشح Bloom متدهور على IVs الرسائل. كل router يحتفظ بمرشح Bloom واحد ليحتوي على XOR للـ IV والكتلة الأولى من الرسالة المستلمة لجميع الـ tunnels التي يشارك فيها، معدل لإزالة الإدخالات المشاهدة بعد 10-20 دقيقة (عندما تنتهي صلاحية الـ tunnels). حجم مرشح bloom والمعاملات المستخدمة كافية لإشباع اتصال الشبكة للـ router أكثر من اللازم مع احتمال ضئيل للإيجابيات الخاطئة. القيمة الفريدة التي تُدخل في مرشح Bloom هي XOR للـ IV والكتلة الأولى لمنع الأقران المتواطئين غير المتتاليين في الـ tunnel من وسم رسالة عن طريق إعادة إرسالها مع تبديل الـ IV والكتلة الأولى.

معالجة نقطة النهاية

بعد استلام والتحقق من رسالة tunnel في القفزة الأخيرة في tunnel، كيفية استعادة نقطة النهاية للبيانات المشفرة بواسطة البوابة تعتمد على ما إذا كان tunnel هو inbound أم outbound tunnel. بالنسبة لـ outbound tunnels، تقوم نقطة النهاية بتشفير الرسالة بمفتاح الطبقة الخاص بها تماماً مثل أي مشارك آخر، مما يكشف البيانات المعالجة مسبقاً. بالنسبة لـ inbound tunnels، فإن نقطة النهاية هي أيضاً منشئ tunnel لذلك يمكنهم ببساطة فك التشفير التكراري لـ IV والرسالة، باستخدام مفاتيح الطبقة وIV لكل خطوة بترتيب عكسي.

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

بناء الـ Tunnel

عند بناء tunnel، يجب على المُنشئ إرسال طلب يحتوي على بيانات التكوين الضرورية إلى كل من القفزات وانتظار موافقة جميعها قبل تفعيل الـ tunnel. يتم تشفير الطلبات بحيث لا يحصل على معلومة معينة (مثل طبقة الـ tunnel أو مفتاح IV) إلا النظراء الذين يحتاجون لمعرفتها. بالإضافة إلى ذلك، سيكون لمُنشئ الـ tunnel فقط إمكانية الوصول إلى ردود النظراء. هناك ثلاثة أبعاد مهمة يجب وضعها في الاعتبار عند إنتاج الـ tunnels: ما هي النظراء المُستخدمة (وأين)، وكيف يتم إرسال الطلبات (واستقبال الردود)، وكيف يتم الحفاظ عليها.

اختيار النظراء

بالإضافة إلى نوعي الـ tunnels - الواردة والصادرة - هناك أسلوبان لاختيار النظراء يُستخدمان للـ tunnels المختلفة - الاستكشافية والعميل. تُستخدم الـ tunnels الاستكشافية لكل من صيانة قاعدة بيانات الشبكة وصيانة الـ tunnel، بينما تُستخدم tunnels العميل لرسائل العميل من نقطة إلى أخرى.

اختيار نظير tunnel الاستكشافي

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

يتم مناقشة اختيار الأقران الاستطلاعي بمزيد من التفصيل في صفحة تصنيف واختيار الأقران .

اختيار نظير tunnel العميل

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

يتم مناقشة اختيار peer العميل بشكل أكبر في صفحة تحليل واختيار النظراء .

ترتيب النظراء داخل الأنفاق

يتم ترتيب النظراء داخل الأنفاق للتعامل مع هجوم السلف (تحديث 2008 ).

لإحباط هجوم السلف، يحتفظ اختيار النفق بالأقران المحددين بترتيب صارم - إذا كان A و B و C في نفق لمجموعة أنفاق معينة، فإن القفزة بعد A هي دائماً B، والقفزة بعد B هي دائماً C.

يتم تنفيذ الترتيب من خلال إنتاج مفتاح عشوائي بحجم 32 بايت لكل tunnel pool عند بدء التشغيل. يجب ألا يتمكن النظراء من تخمين الترتيب، وإلا فقد يتمكن المهاجم من صياغة router hashes متباعدة جداً لزيادة فرصة التواجد في طرفي النفق. يتم ترتيب النظراء حسب مسافة XOR لـ SHA256 Hash الخاص بـ (hash النظير مدموجاً مع المفتاح العشوائي) من المفتاح العشوائي:

      p = peer hash
      k = random key
      d = XOR(H(p+k), k)

لأن كل مجموعة tunnel تستخدم مفتاح عشوائي مختلف، فإن الترتيب يكون متسقًا داخل المجموعة الواحدة ولكن ليس بين المجموعات المختلفة. يتم إنشاء مفاتيح جديدة عند كل إعادة تشغيل للـ router.

تسليم الطلب

يتم بناء tunnel متعدد القفزات باستخدام رسالة بناء واحدة يتم فك تشفيرها وإعادة توجيهها بشكل متكرر. في مصطلحات Hashing it out in Public ، هذا يُسمى بناء tunnel تلسكوبي “غير تفاعلي”.

هذه الطريقة لإعداد وتسليم والاستجابة لطلبات tunnel هي مصممة لتقليل عدد الأسلاف المكشوفين، وتقطع عدد الرسائل المنقولة، وتتحقق من الاتصال السليم، وتتجنب هجوم عد الرسائل في إنشاء tunnel التلسكوبي التقليدي. (هذه الطريقة، التي ترسل رسائل لتوسيع tunnel من خلال الجزء المؤسس بالفعل من tunnel، تُسمى بناء tunnel التلسكوبي “التفاعلي” في ورقة “Hashing it out”.)

تفاصيل رسائل طلب tunnel والاستجابة، وتشفيرها، محددة هنا .

قد ترفض العقد طلبات إنشاء tunnel لأسباب متنوعة، رغم أن هناك سلسلة من أربعة رفضات معروفة تتزايد في الشدة: الرفض الاحتمالي (بسبب الاقتراب من سعة router أو استجابة لفيض من الطلبات)، والحمولة الزائدة المؤقتة، وحمولة bandwidth الزائدة، والفشل الحرج. عند استلامها، يتم تفسير هذه الرفضات الأربعة من قبل منشئ tunnel لمساعدته في تعديل ملف تعريفه للـ router المعني.

للحصول على مزيد من المعلومات حول تقييم الأقران، راجع صفحة تقييم واختيار الأقران .

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

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

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

أطوال الأنفاق والإعدادات الافتراضية

في صفحة نظرة عامة على النفق .

استراتيجية البناء الاستباقية والأولوية

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

لكل مجموعة {استكشافي/عميل، داخل/خارج، الطول، تباين الطول} يحتفظ الـ router بإحصائيات حول الوقت المطلوب لبناء tunnel ناجح. باستخدام هذه الإحصائيات، يحسب كم من الوقت قبل انتهاء صلاحية الـ tunnel يجب أن يبدأ في محاولة بناء بديل. مع اقتراب وقت انتهاء الصلاحية دون نجاح البديل، يبدأ محاولات بناء متعددة بشكل متوازي، وبعد ذلك سيزيد عدد المحاولات المتوازية إذا لزم الأمر.

لتحديد استخدام النطاق الترددي ووحدة المعالجة المركزية، يقوم الـ router أيضًا بتقييد العدد الأقصى لمحاولات البناء المعلقة عبر جميع المجموعات. يتم إعطاء الأولوية للبناءات الحرجة (تلك الخاصة بالـ tunnels الاستكشافية، وللمجموعات التي نفدت منها الـ tunnels).

تنظيم رسائل Tunnel

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

في التطبيق الحالي، تنفذ أجهزة router استراتيجية التجاهل المبكر العشوائي المرجح (WRED). لجميع أجهزة router المشاركة (المشارك الداخلي، وبوابة الدخول inbound gateway، ونقطة الخروج outbound endpoint)، سيبدأ الـ router في إسقاط جزء من الرسائل عشوائياً عندما يتم الاقتراب من حدود النطاق الترددي. كلما اقترب حركة البيانات من الحدود أو تجاوزها، يتم إسقاط رسائل أكثر. بالنسبة للمشارك الداخلي، يتم تجزئة جميع الرسائل وحشوها وبالتالي تصبح بنفس الحجم. في بوابة الدخول inbound gateway ونقطة الخروج outbound endpoint، مع ذلك، يتم اتخاذ قرار الإسقاط على الرسالة الكاملة (المدمجة)، ويؤخذ حجم الرسالة في الاعتبار. الرسائل الأكبر حجماً أكثر عرضة للإسقاط. كما أن الرسائل أكثر عرضة للإسقاط في نقطة الخروج outbound endpoint مقارنة ببوابة الدخول inbound gateway، لأن هذه الرسائل لم تصل بعد إلى مرحلة متقدمة في رحلتها وبالتالي فإن تكلفة الشبكة لإسقاط هذه الرسائل أقل.

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

الخلط/التجميع

ما الاستراتيجيات التي يمكن استخدامها في gateway وفي كل hop لتأخير الرسائل أو إعادة ترتيبها أو إعادة توجيهها أو إضافة padding لها؟ إلى أي مدى يجب أن يتم ذلك تلقائياً، وكم يجب أن يكون قابلاً للتكوين كإعداد لكل tunnel أو لكل hop، وكيف يجب أن يتحكم منشئ tunnel (وبدوره المستخدم) في هذه العملية؟ كل هذا يبقى مجهولاً، ليتم حله في إصدار مستقبلي بعيد.

الحشو

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

WRED

استراتيجيات WRED لها تأثير كبير على الأداء من طرف إلى طرف، ومنع انهيار احتقان الشبكة. يجب تقييم استراتيجية WRED الحالية بعناية وتحسينها.