I2PTunnel

نظرة عامة

I2PTunnel هو أداة للتفاعل مع شبكة I2P وتوفير الخدمات عليها. يمكن تعريف وجهة I2PTunnel باستخدام اسم المضيف ، أو Base32 ، أو مفتاح وجهة كامل بحجم 516 بايت. سيكون I2PTunnel المُنشأ متاحاً على جهاز العميل الخاص بك كـ localhost:port. إذا كنت ترغب في توفير خدمة على شبكة I2P، فما عليك سوى إنشاء I2PTunnel إلى ip_address:port المناسب. سيتم إنتاج مفتاح وجهة مقابل بحجم 516 بايت للخدمة وستصبح متاحة عبر I2P بأكملها. واجهة ويب لإدارة I2PTunnel متاحة على localhost:7657/i2ptunnel/ .

الخدمات الافتراضية

أنفاق الخادم

• I2P Webserver - tunnel يشير إلى خادم ويب Jetty يعمل على localhost:7658 لاستضافة مريحة وسريعة على I2P. الجذر الوثائقي هو:
  • Unix - $HOME/.i2p/eepsite/docroot
  • Windows - %LOCALAPPDATA%\I2P\I2P Site\docroot، والذي يتوسع إلى: C:\Users\**username**\AppData\Local\I2P\I2P Site\docroot

أنفاق العميل

• I2P HTTP Proxy - localhost:4444 - بروكسي HTTP يُستخدم لتصفح I2P والإنترنت العادي بشكل مجهول من خلال I2P. تصفح الإنترنت عبر I2P يستخدم بروكسي عشوائي محدد بواسطة خيار “Outproxies:”.
• Irc2P - localhost:6668 - tunnel IRC إلى شبكة IRC المجهولة الافتراضية، Irc2P.
• gitssh.idk.i2p - localhost:7670 - وصول SSH إلى مستودع Git الخاص بالمشروع
• smtp.postman.i2p - localhost:7659 - خدمة SMTP يوفرها postman في hq.postman.i2p
• pop3.postman.i2p - localhost:7660 - خدمة POP المصاحبة لـ postman في hq.postman.i2p

التكوين

تكوين I2PTunnel

أوضاع العميل

معياري

يفتح منفذ TCP محلي يتصل بخدمة (مثل HTTP أو FTP أو SMTP) على وجهة داخل I2P. يتم توجيه tunnel إلى مضيف عشوائي من قائمة الوجهات المفصولة بفاصلة (", “).

HTTP

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

• Accept*: (لا يشمل “Accept” و “Accept-Encoding”) لأنها تختلف كثيراً بين المتصفحات ويمكن استخدامها كمعرف.
• Referer:
• Via:
• From:

يوفر بروكسي عميل HTTP عددًا من الخدمات لحماية المستخدم وتوفير تجربة مستخدم أفضل.

معالجة رؤوس الطلبات: - إزالة الرؤوس التي تشكل مشاكل خصوصية - التوجيه إلى outproxy محلي أو بعيد - اختيار outproxy والتخزين المؤقت وتتبع إمكانية الوصول - البحث عن اسم المضيف إلى الوجهة - استبدال رأس Host إلى b32 - إضافة رأس للإشارة إلى دعم إلغاء الضغط الشفاف - فرض إغلاق الاتصال - دعم proxy متوافق مع RFC - معالجة وإزالة رؤوس hop-by-hop متوافقة مع RFC - مصادقة اختيارية بـ digest واسم المستخدم/كلمة المرور الأساسية - مصادقة outproxy اختيارية بـ digest واسم المستخدم/كلمة المرور الأساسية - تخزين مؤقت لجميع الرؤوس قبل المرور لتحسين الكفاءة - روابط خادم القفز - معالجة استجابة القفز والنماذج (مساعد العنوان) - معالجة b32 المخفي ونماذج بيانات الاعتماد - يدعم طلبات HTTP و HTTPS (CONNECT) القياسية

معالجة رأس الاستجابة: - فحص ما إذا كان يجب إلغاء ضغط الاستجابة - فرض الاتصال: إغلاق - معالجة وإزالة رؤوس hop-by-hop المتوافقة مع RFC - تخزين جميع الرؤوس مؤقتاً قبل تمريرها لتحسين الكفاءة

استجابات أخطاء HTTP: - للعديد من الأخطاء الشائعة وغير الشائعة، حتى يعرف المستخدم ما حدث - أكثر من 20 صفحة خطأ فريدة مترجمة ومنسقة ومصممة لأخطاء متنوعة - خادم ويب داخلي لتقديم النماذج وCSS والصور والأخطاء

ضغط الاستجابة الشفاف

يتم طلب ضغط استجابة i2ptunnel باستخدام رأس HTTP:

• X-Accept-Encoding: x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0

يقوم جانب الخادم بإزالة هذا الرأس hop-by-hop قبل إرسال الطلب إلى خادم الويب. الرأس المعقد مع جميع قيم q ليس ضرورياً؛ يجب على الخوادم فقط البحث عن “x-i2p-gzip” في أي مكان في الرأس.

يحدد الجانب الخادم ما إذا كان سيضغط الاستجابة بناءً على العناوين المستلمة من خادم الويب، بما في ذلك Content-Type و Content-Length و Content-Encoding، لتقييم ما إذا كانت الاستجابة قابلة للضغط وتستحق المعالج الإضافي المطلوب. إذا قام الجانب الخادم بضغط الاستجابة، فإنه يضيف عنوان HTTP التالي:

• Content-Encoding: x-i2p-gzip

إذا كان هذا الرأس موجوداً في الاستجابة، فإن وكيل HTTP client يقوم بإلغاء ضغطه بشكل شفاف. الجانب العميل يزيل هذا الرأس ويقوم بإلغاء الضغط قبل إرسال الاستجابة إلى المتصفح. لاحظ أنه ما زال لدينا ضغط gzip الأساسي في طبقة I2CP، والذي يظل فعالاً إذا لم تكن الاستجابة مضغوطة في طبقة HTTP.

هذا التصميم والتنفيذ الحالي ينتهكان RFC 2616 بعدة طرق:

• X-Accept-Encoding ليس header معياري
• لا يقوم بفك/تجميع التقسيم لكل قفزة؛ بل يمرر التقسيم من النهاية إلى النهاية
• يمرر header الخاص بـ Transfer-Encoding من النهاية إلى النهاية
• يستخدم Content-Encoding، وليس Transfer-Encoding، لتحديد ترميز كل قفزة
• يمنع ضغط x-i2p gzip عندما يتم تعيين Content-Encoding (لكن ربما لا نريد فعل ذلك على أي حال)
• الجانب الخاص بالخادم يضغط التقسيم المرسل من الخادم، بدلاً من القيام بـ dechunk-gzip-rechunk و dechunk-gunzip-rechunk
• المحتوى المضغوط لا يتم تقسيمه بعد ذلك. RFC 2616 يتطلب أن كل Transfer-Encoding غير “identity” يجب أن يكون مقسم
• لأنه لا يوجد تقسيم خارجي (بعد) الـ gzip، فمن الصعب العثور على نهاية البيانات، مما يجعل أي تنفيذ لـ keepalive أصعب
• RFC 2616 يقول أن Content-Length يجب ألا يُرسل إذا كان Transfer-Encoding موجوداً، لكننا نفعل ذلك. المواصفة تقول تجاهل Content-Length إذا كان Transfer-Encoding موجوداً، وهو ما تفعله المتصفحات، لذا فهو يعمل معنا

التغييرات اللازمة لتنفيذ ضغط hop-by-hop متوافق مع المعايير بطريقة متوافقة مع الإصدارات السابقة هي موضوع للدراسة المستقبلية. أي تغيير على dechunk-gzip-rechunk سيتطلب نوع ترميز جديد، ربما x-i2p-gzchunked. هذا سيكون مطابقاً لـ Transfer-Encoding: gzip، ولكن سيتوجب الإشارة إليه بطريقة مختلفة لأسباب التوافق. أي تغيير سيتطلب اقتراحاً رسمياً.

ضغط الطلبات الشفاف

غير مدعوم، على الرغم من أن POST سيستفيد من ذلك. لاحظ أننا ما زلنا نملك ضغط gzip الأساسي في طبقة I2CP.

الثبات

لا تدعم الخوادم الوكيلة للعميل والخادم حاليًا مقابس HTTP المستمرة وفقًا لمعيار RFC 2616 في أي من القفزات الثلاث (مقبس المتصفح، مقبس I2P، مقبس الخادم). يتم حقن رؤوس Connection: close في كل قفزة. التغييرات اللازمة لتنفيذ الاستمرارية قيد الدراسة. يجب أن تكون هذه التغييرات متوافقة مع المعايير ومتوافقة مع الإصدارات السابقة، ولن تتطلب اقتراحًا رسميًا.

التسلسل

خوادم العميل والخادم الوسيطة لا تدعم حالياً HTTP pipelining وفقاً لمعيار RFC 2616 ولا توجد خطط للقيام بذلك. المتصفحات الحديثة لا تدعم pipelining من خلال الخوادم الوسيطة لأن معظم الخوادم الوسيطة لا تستطيع تنفيذه بشكل صحيح.

التوافق

يجب أن تعمل تطبيقات البروكسي بشكل صحيح مع التطبيقات الأخرى على الجانب الآخر. يجب أن تعمل بروكسيات العميل بدون بروكسي خادم يدعم HTTP (أي tunnel عادي) على جانب الخادم. ليست كل التطبيقات تدعم x-i2p-gzip.

وكيل المستخدم

اعتماداً على ما إذا كان النفق يستخدم outproxy أم لا، فسوف يضيف User-Agent التالي:

• Outproxy: User-Agent: يستخدم وكيل المستخدم من إصدار Firefox حديث على Windows
• الاستخدام الداخلي لـ I2P: User-Agent: MYOB/6.66 (AN/ON)

عميل IRC

ينشئ اتصالاً بخادم IRC عشوائي محدد من قائمة الوجهات المفصولة بفواصل ("، “). يُسمح فقط بمجموعة فرعية مدرجة في القائمة البيضاء من أوامر IRC بسبب مخاوف إخفاء الهوية.

قائمة السماح التالية مخصصة للأوامر الواردة من خادم IRC إلى عميل IRC.

قائمة السماح: - AUTHENTICATE - CAP - ERROR - H - JOIN - KICK - MODE - NICK - PART - PING - PROTOCTL - QUIT - TOPIC - WALLOPS

هناك أيضًا قائمة سماح للأوامر الصادرة من عميل IRC إلى خادم IRC. إنها كبيرة جداً بسبب عدد أوامر إدارة IRC. راجع مصدر IRCFilter.java للتفاصيل.

يقوم المرشح الصادر أيضاً بتعديل الأوامر التالية لإزالة المعلومات المُعرِّفة: - NOTICE - PART - PING - PRIVMSG - QUIT - USER

SOCKS 4/4a/5

يمكّن استخدام router I2P كـ SOCKS proxy.

SOCKS IRC

يمكّن استخدام I2P router كـ SOCKS proxy مع القائمة البيضاء للأوامر المحددة بواسطة وضع عميل IRC .

CONNECT

ينشئ tunnel HTTP ويستخدم طريقة طلب HTTP “CONNECT” لبناء tunnel TCP الذي يُستخدم عادة لـ SSL و HTTPS.

Streamr

ينشئ خادم UDP متصل بعميل Streamr I2PTunnel. نفق عميل streamr سيشترك في نفق خادم streamr.

أوضاع الخادم

قياسي

ينشئ وجهة إلى عنوان ip:port محلي مع منفذ TCP مفتوح.

HTTP

ينشئ وجهة إلى خادم HTTP محلي ip:port. يدعم gzip للطلبات التي تحتوي على Accept-encoding: x-i2p-gzip، ويرد بـ Content-encoding: x-i2p-gzip في مثل هذا الطلب.

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

معالجة رؤوس الطلبات: - التحقق من صحة الرؤوس - حماية من تزوير الرؤوس - فحص أحجام الرؤوس - رفض اختياري لـ inproxy ووكيل المستخدم - إضافة رؤوس X-I2P ليعرف خادم الويب مصدر الطلب - استبدال رأس Host لتسهيل vhosts خادم الويب - فرض اتصال: إغلاق - معالجة وإزالة رؤوس hop-by-hop متوافقة مع RFC - تخزين مؤقت لجميع الرؤوس قبل تمريرها للكفاءة

حماية DDoS: - تحديد معدل طلبات POST - مهلات زمنية وحماية من هجمات slowloris - تحديد إضافي للمعدل يحدث في البث المباشر لجميع أنواع tunnel

معالجة رؤوس الاستجابة: - إزالة بعض الرؤوس التي تشكل مشاكل للخصوصية - فحص نوع Mime والرؤوس الأخرى لتحديد ما إذا كان يجب ضغط الاستجابة - فرض إغلاق الاتصال - معالجة وإزالة الرؤوس المتنقلة (hop-by-hop) وفقاً لمعايير RFC - تخزين جميع الرؤوس مؤقتاً قبل تمريرها لتحسين الكفاءة

استجابات أخطاء HTTP: - للعديد من الأخطاء الشائعة وغير الشائعة وعند التحكم في المعدل، حتى يعرف المستخدم من جانب العميل ما حدث

ضغط الاستجابة الشفاف: - قد يقوم خادم الويب و/أو طبقة I2CP بالضغط، لكن خادم الويب غالباً لا يفعل ذلك، ومن الأكثر كفاءة الضغط في طبقة عالية، حتى لو كانت I2CP تضغط أيضاً. يعمل بروكسي خادم HTTP بشكل تعاوني مع البروكسي من جهة العميل لضغط الاستجابات بشكل شفاف.

HTTP ثنائي الاتجاه

مهجور

يعمل كخادم I2PTunnel HTTP وعميل I2PTunnel HTTP بدون إمكانيات outproxying. مثال على التطبيق قد يكون تطبيق ويب يقوم بطلبات من نوع العميل، أو اختبار loopback لموقع I2P كأداة تشخيصية.

خادم IRC

ينشئ وجهة تقوم بتصفية تسلسل التسجيل للعميل وتمرر مفتاح وجهة العميل كاسم مضيف إلى خادم IRC.

Streamr

يتم إنشاء عميل UDP يتصل بخادم الوسائط. يتم ربط عميل UDP مع خادم Streamr I2PTunnel.