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

دليل استكشاف أخطاء I2P Router وإصلاحها

دليل شامل لاستكشاف أخطاء I2P router الشائعة وإصلاحها، بما في ذلك مشكلات الاتصال والأداء والتهيئة

Updated: 2025-10 Accurate for: 2.10.0

تتعطّل I2P routers في الغالب بسبب مشكلات إعادة توجيه المنافذ، وتخصيص عرض نطاق ترددي غير كافٍ، ووقت تمهيد (bootstrap) غير كافٍ. تمثل هذه العوامل الثلاثة أكثر من 70% من المشكلات المُبلّغ عنها. يحتاج الـ router إلى ما لا يقل عن 10-15 دقيقة بعد بدء التشغيل ليندمج بالكامل مع الشبكة، وحد أدنى لعرض النطاق الترددي قدره 128 KB/sec (يُوصى بـ 256 KB/sec)، وكذلك إعداد إعادة توجيه المنافذ UDP/TCP بطريقة صحيحة للوصول إلى حالة غير محجوبة بجدار ناري. غالباً ما يتوقع المستخدمون الجدد اتصالاً فورياً ويقومون بإعادة التشغيل مبكراً، ما يُعيد ضبط تقدّم الاندماج ويخلق حلقة مزعجة. يوفر هذا الدليل حلولاً مفصلة لجميع المشكلات الرئيسية في I2P التي تؤثر في الإصدارات 2.10.0 فما بعد.

إن معمارية إخفاء الهوية في I2P تقايض السرعة بالخصوصية بشكل متأصل عبر tunnels مشفرة متعددة القفزات. يساعد فهم هذا التصميم الأساسي المستخدمين على وضع توقعات واقعية وحل المشكلات بفعالية بدلاً من إساءة تفسير السلوك الطبيعي على أنه مشاكل.

Router لا يبدأ أو يتعطل فورًا

أكثر أعطال بدء التشغيل شيوعًا تنتج عن تعارض المنافذ، عدم توافق إصدار Java، أو ملفات تهيئة تالفة. تحقق مما إذا كان مثيل آخر لـ I2P يعمل بالفعل قبل استقصاء مشكلات أعمق.

تحقق من عدم وجود عمليات متعارضة:

Linux: ps aux | grep i2p أو netstat -tulpn | grep 7657

Windows: مدير المهام → التفاصيل → ابحث عن java.exe حيث يحتوي سطر الأوامر على i2p

macOS: Activity Monitor → ابحث عن “i2p”

إذا كانت هناك عملية زومبي، فقم بإنهائها: pkill -9 -f i2p (Linux/Mac) أو taskkill /F /IM javaw.exe (Windows)

تحقق من توافق إصدار جافا:

يتطلب I2P 2.10.0+ Java 8 كحدٍّ أدنى، ويُوصى باستخدام Java 11 أو أحدث. تحقّق من أن تثبيتك يُظهر “mixed mode” (وليس “interpreted mode”):

java -version

يجب أن يعرض: OpenJDK أو Oracle Java، الإصدار 8+، “mixed mode”

تجنب: GNU GCJ, تنفيذات Java القديمة, أنماط تعمل بالتفسير فقط

تعارضات المنافذ الشائعة تحدث عندما تتنافس خدمات متعددة على المنافذ الافتراضية لـ I2P. يجب أن تكون منافذ وحدة تحكم router (7657) و I2CP (7654) و SAM (7656) و وكيل HTTP (4444) متاحة. تحقق من وجود تعارضات: netstat -ano | findstr "7657 4444 7654" (ويندوز) أو lsof -i :7657,4444,7654 (لينكس/ماك).

تلف ملف الإعدادات يتجلّى في انهيارات فورية مع أخطاء تحليل في السجلات. Router.config يتطلب ترميز UTF-8 بدون BOM (علامة ترتيب البايتات)، ويستخدم = كفاصل (وليس :)، ويحظر بعض الأحرف الخاصة. أنشئ نسخة احتياطية ثم افحص: ~/.i2p/router.config (Linux), %LOCALAPPDATA%\I2P\router.config (Windows), ~/Library/Application Support/i2p/router.config (macOS).

لإعادة ضبط الإعدادات مع الحفاظ على الهوية: أوقف I2P، وخذ نسخة احتياطية من الملف router.keys ومن دليل keyData، واحذف الملف router.config، ثم أعد التشغيل. سيقوم الـ router بإعادة إنشاء الإعدادات الافتراضية.

انخفاض تخصيص كومة Java يتسبب في أعطال OutOfMemoryError (خطأ نفاد الذاكرة). عدّل wrapper.config وزِد wrapper.java.maxmemory من القيمة الافتراضية 128 أو 256 إلى 512 كحد أدنى (1024 لـ routers عالية النطاق الترددي). يتطلب ذلك إيقافاً كاملاً، والانتظار 11 دقيقة، ثم إعادة التشغيل - النقر على “Restart” في وحدة التحكم لن يطبّق التغيير.

حل حالة “Network: Firewalled”

تعني حالة الحجب بالجدار الناري أن الـ router لا يمكنه تلقي اتصالات واردة مباشرة، مما يفرض الاعتماد على introducers (وسطاء التعريف). ورغم أن الـ router يعمل في هذه الحالة، فإن يتدهور الأداء بشكل كبير وتظل المساهمة في الشبكة ضئيلة للغاية. ويتطلب الوصول إلى حالة غير محجوبة بالجدار الناري إعداد إعادة توجيه المنافذ (port forwarding) بشكل صحيح.

يختار router منفذًا عشوائيًا بين 9000-31000 للاتصالات. اعثر على منفذك في http://127.0.0.1:7657/confignet - ابحث عن “UDP Port” و “TCP Port” (غالبًا ما يكونان الرقم نفسه). يجب عليك إعادة توجيه كلٍ من UDP وTCP لتحقيق أفضل أداء، رغم أن UDP وحده يتيح الوظائف الأساسية.

فعّل إعادة التوجيه التلقائي عبر UPnP (أبسط طريقة):

  1. افتح http://127.0.0.1:7657/confignet
  2. ضع علامة على “Enable UPnP”
  3. احفظ التغييرات وأعد تشغيل router
  4. انتظر 5-10 دقائق وتحقق من تغيّر الحالة من “Network: Firewalled” إلى “Network: OK”

يتطلب UPnP دعم الـ router (مُمكّنًا افتراضيًا على معظم routers المخصصة للمستهلكين المُصنَّعة بعد عام 2010) وتهيئة صحيحة للشبكة.

إعادة توجيه المنافذ يدويًا (مطلوبة عند فشل UPnP):

  1. دوّن منفذ I2P الخاص بك من http://127.0.0.1:7657/confignet (على سبيل المثال، 22648)
  2. اعثر على عنوان IP المحلي لديك: ipconfig (Windows)، ip addr (Linux)، تفضيلات النظام → الشبكة (macOS)
  3. ادخل إلى واجهة إدارة الـ router لديك (عادةً 192.168.1.1 أو 192.168.0.1)
  4. انتقل إلى Port Forwarding (قد يكون ضمن Advanced أو NAT أو Virtual Servers)
  5. أنشئ قاعدتين:
    • المنفذ الخارجي: [your I2P port] → عنوان IP الداخلي: [your computer] → المنفذ الداخلي: [same] → البروتوكول: UDP
    • المنفذ الخارجي: [your I2P port] → عنوان IP الداخلي: [your computer] → المنفذ الداخلي: [same] → البروتوكول: TCP
  6. احفظ الإعدادات وأعد تشغيل الـ router إذا لزم الأمر

تحقق من إعادة توجيه المنفذ باستخدام أدوات التحقق عبر الإنترنت بعد الإعداد. إذا فشلت عملية الكشف، فتحقق من إعدادات جدار الحماية - يجب أن يسمح كلٌ من جدار حماية النظام وأي جدار حماية تابع لبرنامج مكافحة الفيروسات بمنفذ I2P.

بديل وضع Hidden mode للشبكات المقيِّدة حيث تكون إعادة توجيه المنافذ مستحيلة: قم بتمكينه من http://127.0.0.1:7657/confignet → حدِّد “Hidden mode”. يظل router خلف جدار ناري لكنه يُحسّن عمله لهذا الوضع عبر استخدام SSU introducers (وسطاء التعارف عبر SSU) حصراً. سيكون الأداء أبطأ لكنه سيظل قابلاً للاستخدام.

Router عالق في حالتي “قيد البدء” أو “قيد الاختبار”

هذه الحالات العابرة أثناء التمهيد الأولي تزول عادةً خلال 10-15 دقيقة لعمليات التثبيت الجديدة أو 3-5 دقائق لـ routers المستقرة. غالباً ما يؤدي التدخل المبكر إلى تفاقم المشاكل.

“Network: Testing” تشير إلى أن الـrouter يفحص إمكانية الوصول عبر أنواع اتصال متعددة (مباشر، introducers (وسطاء التعريف)، إصدارات متعددة من البروتوكول). هذا أمر طبيعي خلال أول 5-10 دقائق بعد بدء التشغيل. يختبر الـrouter عدة سيناريوهات لتحديد الإعداد الأمثل.

تظهر “Rejecting tunnels: starting up” أثناء bootstrap (مرحلة التهيئة الأولية) عندما يفتقر الـrouter إلى معلومات كافية عن النظراء. لن يشارك الـrouter في حركة المرور المرحّلة حتى يتم دمجه بشكل كافٍ. ينبغي أن تختفي هذه الرسالة بعد 10-20 دقيقة بمجرد أن يمتلئ netDb بـ 50+ routers.

انحراف الساعة يعطّل اختبار قابلية الوصول. تتطلب I2P أن يكون وقت النظام ضمن ±60 ثانية من وقت الشبكة. يؤدي تجاوز الفرق 90 ثانية إلى رفض الاتصال تلقائيًا. قم بمزامنة ساعة نظامك:

لينكس: sudo timedatectl set-ntp true && sudo systemctl restart systemd-timesyncd

Windows: لوحة التحكم → التاريخ والوقت → وقت الإنترنت → تحديث الآن → تمكين المزامنة التلقائية

macOS: تفضيلات النظام → التاريخ والوقت → فعّل “ضبط التاريخ والوقت تلقائيًا”

بعد تصحيح انحراف الساعة، أعد تشغيل I2P بالكامل لضمان التكامل الصحيح.

عدم كفاية تخصيص عرض النطاق الترددي يمنع نجاح الاختبار. يحتاج الـ router إلى سعة كافية لبناء tunnels للاختبار. قم بالإعداد على http://127.0.0.1:7657/config:

  • الحد الأدنى القابل للاستخدام: الوارد 96 KB/sec، الصادر 64 KB/sec
  • المعيار الموصى به: الوارد 256 KB/sec، الصادر 128 KB/sec
  • الأداء الأمثل: الوارد 512+ KB/sec، الصادر 256+ KB/sec
  • نسبة المشاركة: 80% (يسمح لـ router بالمساهمة في عرض النطاق الترددي للشبكة)

قد يعمل عرض النطاق الترددي المنخفض، لكنه يطيل وقت الاندماج من دقائق إلى ساعات.

تلف netDb الناتج عن إيقاف تشغيل غير سليم أو أخطاء القرص يسبب حلقات اختبار لا نهائية. لا يمكن لـ router إكمال الاختبار دون بيانات أقران صالحة:

# Stop I2P completely
i2prouter stop    # or systemctl stop i2p

# Delete corrupted database (safe - will reseed automatically)
rm -rf ~/.i2p/netDb/*

# Restart and allow 10-15 minutes for reseed
i2prouter start

ويندوز: احذف محتويات %APPDATA%\I2P\netDb\ أو %LOCALAPPDATA%\I2P\netDb\

حظر جدار الحماية لعملية reseed (إعادة البذر الأوّلي للنظراء) يمنع الحصول على النظراء الأوّليين. أثناء عملية bootstrap (التمهيد)، يسترجع I2P معلومات الـ router من خوادم reseed عبر HTTPS. قد تقوم جدران حماية الشركات أو مزوّدي خدمة الإنترنت بحظر هذه الاتصالات. قم بإعداد وكيل reseed على http://127.0.0.1:7657/configreseed إذا كنت تعمل خلف شبكات مقيِّدة.

سرعات بطيئة، حالات انتهاء المهلة، وإخفاقات في إنشاء tunnel

يؤدي تصميم I2P بطبيعته إلى تحقيق سرعات أبطأ بمقدار 3-10x من clearnet (الإنترنت المكشوف) بسبب التعمية متعددة القفزات، والكلفة الإضافية في الحزم، وعدم إمكانية التنبؤ بالمسارات. عملية إنشاء tunnel تجتاز عدّة routers، ويضيف كلّ منها كمونًا. إن فهم ذلك يمنع إساءة تشخيص السلوك الطبيعي على أنه مشكلات.

توقعات الأداء النموذجية:

  • تصفح مواقع .i2p: يستغرق تحميل الصفحات في البداية 10-30 ثانية، ويصبح أسرع بعد إنشاء tunnel
  • التحميل عبر بروتوكول التورنت باستخدام I2PSnark: 10-100 كيلوبايت/ثانية لكل تورنت بحسب عدد المزوّدين (seeders) وظروف الشبكة
  • تنزيل الملفات الكبيرة: الصبر مطلوب - قد تستغرق الملفات بحجم ميغابايت دقائق، والغيغابايت ساعات
  • أول اتصال هو الأبطأ: يستغرق بناء tunnel 30-90 ثانية; الاتصالات اللاحقة تستخدم tunnels الموجودة

معدل نجاح إنشاء Tunnel يشير إلى صحة الشبكة. تحقق عبر http://127.0.0.1:7657/tunnels:

  • أعلى من 60٪: تشغيل طبيعي وسليم
  • 40-60٪: هامشي، فكّر في زيادة عرض النطاق الترددي أو تقليل الحمل
  • أقل من 40٪: إشكالي - يشير إلى عدم كفاية عرض النطاق الترددي، أو مشكلات في الشبكة، أو سوء اختيار النظراء

زِد تخصيص عرض النطاق الترددي كأول تحسين. معظم بطء الأداء ينجم عن نقص في عرض النطاق الترددي. في http://127.0.0.1:7657/config، زِد الحدود تدريجيًا وراقب الرسوم البيانية في http://127.0.0.1:7657/graphs.

لـ DSL/Cable (اتصالات 1-10 Mbps): - الوارد: 400 KB/sec - الصادر: 200 KB/sec - نسبة المشاركة: 80% - الذاكرة: 384 MB (قم بتحرير wrapper.config)

للاتصالات عالية السرعة (10-100+ Mbps): - وارد: 1500 KB/sec - صادر: 1000 KB/sec - المشاركة: 80-100% - الذاكرة: 512-1024 MB - ضع في الاعتبار: زيادة عدد الـ tunnels المشاركة إلى 2000-5000 في http://127.0.0.1:7657/configadvanced

حسّن تكوين tunnel لأداء أفضل. ادخل إلى إعدادات tunnel المحددة على http://127.0.0.1:7657/i2ptunnel وقم بتحرير كل tunnel:

  • عدد الـ Tunnel: قم بزيادته من 2 إلى 3-4 (المزيد من المسارات المتاحة)
  • عدد النسخ الاحتياطية: اضبطه على 1-2 (تحويل سريع عند فشل tunnel)
  • طول الـ Tunnel: الإعداد الافتراضي 3 قفزات يوفّر توازناً جيداً؛ خفضه إلى 2 يحسّن السرعة لكنه يقلّل إخفاء الهوية

مكتبة التشفير الأصلية (jbigi) توفر أداءً أفضل بمقدار 5–10 أضعاف مقارنةً بتشفير Java الخالص. تحقّق من تحميلها في http://127.0.0.1:7657/logs - ابحث عن “jbigi loaded successfully” أو “Using native CPUID implementation”. إن لم تكن موجودة:

لينكس: عادةً ما يتم اكتشافه تلقائيًا وتحميله من ~/.i2p/jbigi-*.so ويندوز: تحقّق من وجود jbigi.dll في دليل تثبيت I2P إذا كان مفقودًا: ثبّت أدوات البناء وقم ببنائه من المصدر، أو نزّل الثنائيات المُترجَمة مسبقًا من المستودعات الرسمية

أبقِ router يعمل بشكل مستمر. كل إعادة تشغيل تعيد ضبط اندماجه في الشبكة، وتتطلب 30-60 دقيقة لإعادة بناء شبكة tunnel وعلاقات الأقران. تحظى routers المستقرة ذات زمن التشغيل المرتفع بتفضيل عند اختيارها لبناء tunnel، مما يخلق تغذية راجعة إيجابية للأداء.

ارتفاع استهلاك وحدة المعالجة المركزية والذاكرة

يشير الاستخدام المفرط للموارد عادةً إلى تخصيص غير كافٍ للذاكرة أو غياب مكتبات التشفير الأصلية أو الالتزام المفرط بالمشاركة في الشبكة. ينبغي أن تستهلك routers المُكوَّنة جيدًا 10-30% من وحدة المعالجة المركزية أثناء الاستخدام النشط، وأن تحافظ على استقرار الذاكرة دون 80% من heap (ذاكرة الكومة) المخصصة.

تتجلى مشكلات الذاكرة في: - رسوم بيانية للذاكرة ذات قمة مسطحة (مثبتة عند الحد الأقصى) - جمع القمامة المتكرر (نمط سنّ المنشار مع انخفاضات حادّة) - OutOfMemoryError في السجلات - Router يصبح غير مستجيب تحت الحمل - إيقاف تلقائي بسبب استنزاف الموارد

زيادة تخصيص ذاكرة الكومة في Java في wrapper.config (يتطلب إيقاف التشغيل بالكامل):

# Linux: ~/.i2p/wrapper.config
# Windows: %APPDATA%\I2P\wrapper.config  
# Find and modify:
wrapper.java.maxmemory=512

# Recommendations by usage:
# Light browsing only: 256
# Standard use (browsing + light torrenting): 512
# Heavy use (multiple applications, active torrenting): 768-1024
# Floodfill or very high bandwidth: 1024-2048

هام جدًا: بعد تعديل wrapper.config، يجب إيقاف التشغيل بالكامل (عدم إعادة التشغيل)، انتظر 11 دقيقة لإنهاء سلس، ثم ابدأ تشغيلًا جديدًا. زر “Restart” في لوحة تحكم الـ Router لا يعيد تحميل إعدادات الـ wrapper (المُغلِّف).

يتطلب تحسين أداء CPU وجود مكتبة تشفير أصلية (native). تستهلك عمليات BigInteger في Java الخالصة CPU أكثر بمقدار 10-20x مقارنة بالتنفيذات الأصلية. تحقق من حالة jbigi على http://127.0.0.1:7657/logs أثناء بدء التشغيل. بدون jbigi، سيرتفع استخدام CPU إلى 50-100% أثناء بناء tunnel (مسار اتصال في I2P) وعمليات التشفير.

قلّل حمل tunnel المشاركة إذا كان router مثقلاً بالأحمال:

  1. ادخل إلى http://127.0.0.1:7657/configadvanced
  2. اضبط router.maxParticipatingTunnels=1000 (الافتراضي 8000)
  3. قلّل نسبة المشاركة في http://127.0.0.1:7657/config من 80% إلى 50%
  4. عطّل وضع floodfill إذا كان مفعّلًا: router.floodfillParticipant=false

قيّد عرض النطاق الترددي في I2PSnark وعدد التورنتات المتزامنة. استخدام التورنت يستهلك قدراً كبيراً من الموارد. في http://127.0.0.1:7657/i2psnark:

  • حدِّد عدد التورنتات النشطة إلى 3-5 كحد أقصى
  • اضبط “Up BW Limit” و"Down BW Limit" على قيم معقولة (50-100 كيلوبايت/ثانية لكل منهما)
  • أوقف ملفات التورنت عند عدم الحاجة إليها فعلياً
  • تجنّب البذر (seeding) لعشرات ملفات التورنت في وقت واحد

راقب استخدام الموارد عبر الرسوم البيانية المدمجة على http://127.0.0.1:7657/graphs. يجب أن تُظهر الذاكرة هامشاً احتياطياً، لا أن تكون مسطحة عند الحد الأقصى. تُعد الارتفاعات الحادة في CPU أثناء بناء tunnel أمراً طبيعياً؛ أما الارتفاع المرتفع والمستمر في CPU فيشير إلى مشكلات في الإعداد.

للأنظمة المحدودة الموارد بشدة (Raspberry Pi، أجهزة قديمة)، فكّر في استخدام i2pd (تنفيذ بلغة C++) كبديل. يتطلب i2pd ~130 MB من ذاكرة RAM مقابل 350+ MB لـ Java I2P، ويستخدم ~7% من وحدة المعالجة المركزية مقابل 70% تحت أحمال مماثلة. لاحظ أن i2pd يفتقر إلى التطبيقات المدمجة ويتطلب أدوات خارجية.

مشكلات تورنت I2PSnark

يتطلب تكامل I2PSnark مع معمارية الـ router في I2P فهم أن يعتمد استخدام التورنت اعتمادًا كاملًا على صحة الـ tunnel الخاصة بالـ router. لن تبدأ التورنتات حتى يحقق الـ router تكاملًا كافيًا مع أكثر من 10 نظراء نشطين وتكون لديه tunnels عاملة.

التورنت العالقة عند 0% تشير عادةً إلى:

  1. Router غير مُندمج بالكامل: انتظر 10–15 دقيقة بعد بدء تشغيل I2P قبل توقّع أي نشاط للتورنت
  2. تم تعطيل DHT (جدول تجزئة موزّع): فعِّل ذلك على http://127.0.0.1:7657/i2psnark → Configuration → فعِّل الخيار “Enable DHT” (مفعّل افتراضيًا منذ الإصدار 0.9.2)
  3. متعقّبات غير صالحة أو متوقّفة: تتطلّب تورنتات I2P متعقّبات مخصّصة لـ I2P - متعقّبات clearnet (الإنترنت الواضح) لن تعمل
  4. إعدادات tunnel غير كافية: زِد عدد الـ tunnels من I2PSnark Configuration → قسم Tunnels

اضبط I2PSnark tunnels لتحسين الأداء:

  • tunnels الواردة: 3-5 (القيمة الافتراضية 2 لـ Java I2P، و5 لـ i2pd)
  • tunnels الصادرة: 3-5
  • طول tunnel: 3 قفزات (يمكن تقليله إلى 2 لزيادة السرعة، مع تقليل مستوى إخفاء الهوية)
  • عدد tunnels: 3 (يوفّر أداءً متسقاً)

متتبعات تورنت I2P الضرورية لإضافتها: - tracker2.postman.i2p (الرئيسي، الأكثر موثوقية) - w7tpbzncbcocrqtwwm3nezhnnsw4ozadvi2hmvzdhrqzfxfum7wa.b32.i2p/a

أزل أي متتبعات clearnet (غير .i2p) - فهي لا تقدم أي قيمة وتُنشئ محاولات اتصال تنتهي بانقضاء المهلة.

أخطاء “Torrent not registered” تحدث عند فشل الاتصال بخادم التتبع. يؤدي النقر بزر الماوس الأيمن على التورنت → “Start” إلى فرض إعادة الإعلان إلى خادم التتبع. إذا استمرت المشكلة، فتحقق من إمكانية الوصول إلى خادم التتبع عبر تصفح http://tracker2.postman.i 2p في متصفح مُعدّ لـ I2P. يجب استبدال خوادم التتبع المعطّلة ببدائل عاملة.

لا يوجد أقران يتصلون رغم نجاح المتتبع، مما يشير إلى: - Router محجوب بجدار ناري (يتحسن الأمر مع إعادة توجيه المنافذ لكنه غير مطلوب) - عرض نطاق غير كافٍ (ارفعه إلى 256+ KB/sec) - Swarm (مجموعة المشاركين) صغيرة جداً (بعض ملفات التورنت لديها 1-2 seeders (المزوّدون)؛ الصبر مطلوب) - DHT (جدول التجزئة الموزع) معطّل (فعّله لاكتشاف الأقران بدون متتبع)

فعِّل DHT و PEX (تبادل الأقران) ضمن إعدادات I2PSnark. يتيح DHT (جدول تجزئة موزع) العثور على الأقران دون الاعتماد على المتعقّب. يكتشف PEX الأقران من خلال الأقران المتصلين، مما يسرّع اكتشاف السرب.

تلف الملفات التي تم تنزيلها يحدث نادراً مع آلية التحقق من السلامة المدمجة في I2PSnark. إذا تم اكتشافه:

  1. انقر بزر الفأرة الأيمن على التورنت → “Check” يفرض إعادة حساب الهاش لجميع القطع
  2. احذف بيانات التورنت التالفة (يحتفظ بملف .torrent)
  3. انقر بزر الفأرة الأيمن → “Start” لإعادة التنزيل مع التحقق من القطع
  4. افحص القرص بحثًا عن أخطاء إذا استمر التلف: chkdsk (Windows)، fsck (Linux)

مجلد المراقبة لا يعمل يتطلب تهيئة صحيحة:

  1. إعدادات I2PSnark → “Watch directory”: حدِّد المسار المطلق (مثال: /home/user/torrents/watch)
  2. تأكّد من أن عملية I2P تمتلك صلاحيات القراءة: chmod 755 /path/to/watch
  3. ضع ملفات .torrent في دليل المراقبة - سيقوم I2PSnark بإضافتها تلقائياً
  4. اضبط “Auto start”: حدِّد ما إذا كان ينبغي أن تبدأ ملفات التورنت مباشرةً عند إضافتها

تحسين الأداء لاستخدام التورنت:

  • حدّد عدد ملفات تورنت النشطة بالتزامن: 3-5 كحد أقصى للاتصالات القياسية
  • امنح الأولوية للتنزيلات المهمة: أوقف ملفات تورنت ذات أولوية منخفضة مؤقتاً
  • زِد تخصيص عرض النطاق لـ router: عرض نطاق أكبر = أداء تورنت أفضل
  • تحلَّ بالصبر: التورنت عبر I2P أبطأ بطبيعته من BitTorrent على الإنترنت المكشوف (clearnet)
  • استمر في الرفع بعد التنزيل: الشبكة تزدهر بالمعاملة بالمثل

إعداد Git عبر I2P واستكشاف الأخطاء وإصلاحها

تتطلب عمليات Git عبر I2P إما تهيئة وكيل SOCKS أو I2P tunnels مخصصة للوصول عبر SSH/HTTP. يفترض تصميم Git اتصالات منخفضة الكمون، مما يجعل بنية I2P عالية الكمون تحديًا.

تهيئة Git لاستخدام وكيل SOCKS الخاص بـ I2P:

حرّر ~/.ssh/config (أنشئه إذا لم يكن موجودًا):

Host *.i2p
    ProxyCommand nc -X 5 -x 127.0.0.1:4447 %h %p
    ServerAliveInterval 60
    ServerAliveCountMax 3
    Compression yes

يقوم هذا بتوجيه جميع اتصالات SSH إلى مضيفي ‎.i2p‎ عبر وكيل SOCKS الخاص بـ I2P (المنفذ 4447). تحافظ إعدادات ServerAlive (إعدادات إبقاء الجلسة نشطة) على الاتصال أثناء كمون I2P.

بالنسبة لعمليات Git (نظام إدارة الإصدارات الموزّع) عبر HTTP/HTTPS، قم بتهيئة Git على مستوى المستخدم:

git config --global http.proxy socks5h://127.0.0.1:4447
git config --global https.proxy socks5h://127.0.0.1:4447

ملاحظة: socks5h يقوم بإجراء حل نظام أسماء النطاقات (DNS) عبر الوكيل - وهو أمر بالغ الأهمية لنطاقات .i2p.

إنشاء I2P tunnel مخصص لـ Git عبر SSH (أكثر موثوقية من SOCKS):

  1. ادخل إلى http://127.0.0.1:7657/i2ptunnel
  2. “tunnel عميل جديد” → “قياسي”
  3. قم بالتهيئة:
    • الاسم: Git-SSH
    • النوع: عميل
    • المنفذ: 2222 (منفذ محلي للوصول إلى Git)
    • الوجهة: [your-git-server].i2p:22
    • بدء تلقائي: مفعّل
    • عدد tunnel: 3-4 (أعلى لزيادة الموثوقية)
  4. احفظ وابدأ tunnel
  5. اضبط SSH لاستخدام tunnel: ssh -p 2222 git@127.0.0.1

أخطاء مصادقة SSH عبر I2P عادةً ما تنجم عن:

  • لم يتم إضافة المفتاح إلى ssh-agent: ssh-add ~/.ssh/id_rsa
  • أذونات ملف المفتاح غير صحيحة: chmod 600 ~/.ssh/id_rsa
  • tunnel غير قيد التشغيل: تحقق عبر http://127.0.0.1:7657/i2ptunnel أن الحالة خضراء
  • خادم Git يتطلب نوع مفتاح محدداً: أنشئ مفتاح ed25519 إذا فشل RSA

انتهاء المهلة في عمليات Git يرتبط بخصائص الكمون في I2P:

  • زد مهلة Git: git config --global http.postBuffer 524288000 (مخزن مؤقت بحجم 500MB)
  • زد حد السرعة المنخفضة: git config --global http.lowSpeedLimit 1000 و git config --global http.lowSpeedTime 600 (ينتظر 10 دقائق)
  • استخدم استنساخًا سطحيًا في البداية: git clone --depth 1 [url] (يجلب أحدث التزام فقط، أسرع)
  • استنسخ خلال فترات انخفاض النشاط: ازدحام الشبكة يؤثر في أداء I2P

عمليات git clone/fetch البطيئة متأصلة في معمارية I2P. قد يستغرق مستودع بحجم 100MB مدة 30–60 دقيقة عبر I2P، مقابل ثوانٍ على الإنترنت المكشوف (clearnet). استراتيجيات:

  • استخدم الاستنساخات السطحية: --depth 1 يقلّل بشكل كبير من نقل البيانات الأولي
  • اجلب بشكل تدريجي: بدلًا من الاستنساخ الكامل، اجلب فروعًا محددة: git fetch origin branch:branch
  • فكّر في استخدام rsync عبر I2P: بالنسبة للمستودعات الكبيرة جدًا، قد يقدّم rsync أداءً أفضل
  • زد عدد tunnel: المزيد من tunnels يوفّر معدل نقل أفضل لعمليات النقل الكبيرة المستمرة

أخطاء “Connection refused” تشير إلى سوء تهيئة tunnel:

  1. تحقّق من أن I2P router قيد التشغيل: زر http://127.0.0.1:7657
  2. أكّد أن tunnel نشط وباللون الأخضر على http://127.0.0.1:7657/i2ptunnel
  3. اختبر tunnel: nc -zv 127.0.0.1 2222 (يجب أن يتصل إذا كان tunnel يعمل)
  4. تحقّق من إمكانية الوصول إلى الوجهة: تصفّح واجهة HTTP الخاصة بالوجهة إن كانت متاحة
  5. راجع سجلات tunnel في http://127.0.0.1:7657/logs بحثًا عن أخطاء محددة

أفضل الممارسات لاستخدام Git عبر I2P:

  • حافظ على تشغيل I2P router بشكل مستمر للحصول على وصول مستقر إلى Git
  • استخدم مفاتيح SSH بدلاً من المصادقة بكلمة مرور (مطالبات تفاعلية أقل)
  • قم بتهيئة tunnels دائمة بدلاً من اتصالات SOCKS المؤقتة
  • فكّر في استضافة خادم git عبر I2P الخاص بك لمزيد من التحكّم
  • وثّق نقاط نهاية git الخاصة بك على .i2p للمتعاونين

الوصول إلى eepsites وحل أسماء نطاقات .i2p

السبب الأكثر شيوعًا لعدم تمكن المستخدمين من الوصول إلى مواقع .i2p هو تكوين وكيل المتصفح غير الصحيح. مواقع I2P موجودة فقط داخل شبكة I2P وتتطلب التوجيه عبر وكيل HTTP الخاص بـ I2P.

اضبط إعدادات وكيل المتصفح تمامًا:

فايرفوكس (موصى به لـ I2P):

  1. القائمة → الإعدادات → إعدادات الشبكة → زر الإعدادات
  2. اختر “تكوين الوكيل اليدوي”
  3. وكيل HTTP: 127.0.0.1 المنفذ: 4444
  4. وكيل SSL: 127.0.0.1 المنفذ: 4444
  5. وكيل SOCKS: 127.0.0.1 المنفذ: 4447 (اختياري، لتطبيقات SOCKS)
  6. حدّد “تمرير DNS عبر الوكيل عند استخدام SOCKS v5”
  7. انقر موافق للحفظ

الإعدادات الحرجة في about:config الخاصة بـ Firefox:

انتقل إلى about:config وعدّل:

  • media.peerconnection.ice.proxy_only = true (يمنع تسريبات عناوين IP عبر WebRTC (الاتصال في الوقت الحقيقي عبر الويب))
  • keyword.enabled = false (يمنع إعادة توجيه عناوين .i2p إلى محركات البحث)
  • network.proxy.socks_remote_dns = true (DNS عبر الوكيل)

قيود Chrome/Chromium:

يستخدم Chrome إعدادات البروكسي على مستوى النظام بدلاً من الإعدادات الخاصة بالتطبيق. على Windows: الإعدادات → ابحث عن “proxy” → “افتح إعدادات البروكسي في جهازك” → اضبط HTTP: 127.0.0.1:4444 و HTTPS: 127.0.0.1:4445.

مقاربة أفضل: استخدم إضافة FoxyProxy أو Proxy SwitchyOmega للتوجيه الانتقائي لعناوين ‎.i2p.

أخطاء “Website Not Found In Address Book” تعني أن الـ router يفتقر إلى العنوان التشفيري لنطاق .i2p. يستخدم I2P دفاتر عناوين محلية بدلاً من نظام أسماء النطاقات (DNS) المركزي. الحلول:

الطريقة 1: استخدم jump services (خدمات القفز) (الأسهل للمواقع الجديدة):

انتقل إلى http://stats.i 2p وابحث عن الموقع. انقر رابط addresshelper: http://example.i2p/?i2paddresshelper=base64destination. سيعرض متصفحك “Save to addressbook?” - أكِّد الإضافة.

الطريقة 2: تحديث اشتراكات دفتر العناوين:

  1. انتقل إلى http://127.0.0.1:7657/dns (SusiDNS)
  2. انقر علامة التبويب “Subscriptions”
  3. تحقق من الاشتراكات النشطة (الافتراضي: http://i2p-projekt.i 2p/hosts.txt)
  4. أضف الاشتراكات الموصى بها:
  5. انقر “Update Now” لفرض التحديث الفوري للاشتراكات
  6. انتظر 5-10 دقائق لإتمام المعالجة

الطريقة الثالثة: استخدم عناوين base32 (تعمل دائمًا إذا كان الموقع متاحًا على الإنترنت):

كل موقع ‎.i2p‎ له عنوان Base32: 52 حرفًا عشوائيًا تليها ‎.b32.i2p‎ (على سبيل المثال، ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p). تتخطّى عناوين Base32 الـ addressbook (دفتر العناوين) - يقوم الـ router بإجراء استعلام تشفيري مباشر.

أخطاء شائعة في إعداد المتصفح:

  • محاولة استخدام HTTPS على مواقع مقتصرة على HTTP: معظم مواقع .i2p تستخدم HTTP فقط - ستفشل محاولة https://example.i2p
  • نسيان بادئة http://: قد يقوم المتصفح بالبحث بدلًا من الاتصال - استخدم دائمًا http://example.i2p
  • تمكين WebRTC: قد يسرّب عنوان IP الحقيقي - عطّله عبر إعدادات Firefox أو عبر الإضافات
  • DNS غير مُمرَّر عبر وكيل: لا يستطيع DNS الخاص بـ clearnet (الإنترنت العادي/العلني) حلّ نطاقات .i2p - يجب تمرير استعلامات DNS عبر الوكيل
  • منفذ الوكيل غير صحيح: 4444 لـ HTTP (وليس 4445، لأنه HTTPS outproxy (وكيل خروج) إلى clearnet)

Router غير مندمج بالكامل يمنع الوصول إلى أي موقع. تحقق من كفاية الاندماج:

  1. تحقق من أن http://127.0.0.1:7657 يعرض “Network: OK” أو “Network: Firewalled” (وليس “Network: Testing”)
  2. يجب أن يعرض Active peers 10+ كحد أدنى (50+ أمثل)
  3. لا تظهر الرسالة “Rejecting tunnels: starting up”
  4. انتظر 10-15 دقيقة كاملة بعد بدء تشغيل router قبل توقع الوصول إلى .i2p

إعدادات IRC وعميل البريد الإلكتروني تتبع أنماطاً متشابهة للوكيل:

IRC: يتصل العملاء بـ 127.0.0.1:6668 (IRC proxy tunnel الخاص بـ I2P). عطّل إعدادات الوكيل في عميل IRC - الاتصال بـ localhost:6668 مُمرَّر بالفعل عبر I2P.

البريد الإلكتروني (Postman): - SMTP: 127.0.0.1:7659 - POP3: 127.0.0.1:7660 - بدون SSL/TLS (يتم تولّي التشفير بواسطة I2P tunnel) - بيانات الاعتماد من تسجيل حساب postman.i2p

يجب أن تُظهر جميع هذه الـ tunnels حالة “running” (باللون الأخضر) على http://127.0.0.1:7657/i2ptunnel.

إخفاقات التثبيت ومشكلات الحزم

تفشل عمليات التثبيت المبنية على الحزم (Debian وUbuntu وArch) أحياناً بسبب تغييرات المستودعات، أو انتهاء صلاحية مفتاح GPG، أو تعارضات التبعيات. لقد تغيّرت المستودعات الرسمية من deb.i2p2.de/deb.i2p2.no (انتهى الدعم) إلى deb.i2p.net في الإصدارات الأخيرة.

تحديث مستودع Debian/Ubuntu إلى الإصدار الحالي:

# Remove old repository entries
sudo rm /etc/apt/sources.list.d/i2p.list

# Add current repository
echo "deb [signed-by=/usr/share/keyrings/i2p-archive-keyring.gpg] https://deb.i2p.net/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/i2p.list

# Download and install current signing key
curl -o i2p-archive-keyring.gpg https://geti2p.net/_static/i2p-archive-keyring.gpg
sudo cp i2p-archive-keyring.gpg /usr/share/keyrings/

# Update and install
sudo apt update
sudo apt install i2p i2p-keyring

إخفاقات التحقق من توقيعات GPG تحدث عندما تنتهي صلاحية مفاتيح المستودع أو تتغير:

# Error: "The following signatures were invalid"
# Solution: Install current keyring package
sudo apt install i2p-keyring

# Manual key import if package unavailable
wget https://geti2p.net/_static/i2p-debian-repo.key.asc
sudo apt-key add i2p-debian-repo.key.asc

تعذّر بدء الخدمة بعد تثبيت الحزمة غالبًا ما ينتج عن مشكلات في ملفات تعريف AppArmor على Debian/Ubuntu:

# Check service status
sudo systemctl status i2p.service

# Common error: "Failed at step APPARMOR spawning"
# Solution: Reconfigure without AppArmor
sudo dpkg-reconfigure -plow i2p
# Select "No" for AppArmor when prompted

# Alternative: Set profile to complain mode
sudo aa-complain /usr/sbin/wrapper

# Check logs for specific errors  
sudo journalctl -xe -u i2p.service

مشكلات الأذونات في I2P المثبّت عبر الحزمة:

# Fix ownership (package install uses 'i2psvc' user)
sudo chown -R i2psvc:i2psvc /var/lib/i2p /var/log/i2p /run/i2p
sudo chmod 750 /var/log/i2p /var/lib/i2p

# Set file descriptor limits (add to /etc/security/limits.conf)
i2psvc soft nofile 4096  
i2psvc hard nofile 8192

مشكلات التوافق مع Java:

يتطلب I2P 2.10.0 Java 8 كحد أدنى. قد تعمل الأنظمة الأقدم بـ Java 7 أو أقدم:

# Check Java version
java -version

# Install appropriate Java (Debian/Ubuntu)
sudo apt install openjdk-11-jre-headless

# Set default Java if multiple versions installed
sudo update-alternatives --config java

أخطاء تهيئة Wrapper تمنع بدء تشغيل الخدمة:

يختلف موقع Wrapper.config حسب طريقة التثبيت: - تثبيت المستخدم: ~/.i2p/wrapper.config - تثبيت الحزمة: /etc/i2p/wrapper.config أو /var/lib/i2p/wrapper.config

مشكلات wrapper.config الشائعة:

  • مسارات غير صحيحة: يجب أن يشير wrapper.java.command إلى تثبيت Java صالح
  • ذاكرة غير كافية: تم ضبط wrapper.java.maxmemory على قيمة منخفضة جداً (زِدها إلى 512+)
  • موقع ملف PID غير صحيح: يجب أن يشير wrapper.pidfile إلى موقع قابل للكتابة
  • غياب الثنائي الخاص بـ wrapper (أداة تغليف): بعض المنصات تفتقر إلى نسخة wrapper مبنية مسبقاً (استخدم runplain.sh كحل احتياطي)

إخفاقات التحديث والتحديثات التالفة:

تفشل تحديثات وحدة تحكم router أحيانًا في منتصف التنزيل بسبب انقطاعات الشبكة. إجراء التحديث اليدوي:

  1. نزّل i2pupdate_X.X.X.zip من https://geti2p.net/en/download
  2. تحقّق من أن المجموع الاختباري SHA256 يطابق الهاش المنشور
  3. انسخ إلى دليل تثبيت I2P باسم i2pupdate.zip
  4. أعد تشغيل router - سيكتشف التحديث ويستخرجه تلقائيًا
  5. انتظر 5-10 دقائق حتى يكتمل تثبيت التحديث
  6. تحقّق من الإصدار الجديد على http://127.0.0.1:7657

الترحيل من إصدارات قديمة جدًا (ما قبل 0.9.47) إلى الإصدارات الحالية قد يفشل بسبب مفاتيح توقيع غير متوافقة أو ميزات تمت إزالتها. التحديثات التدريجية مطلوبة:

  • الإصدارات الأقدم من 0.9.9: لا يمكن التحقق من التواقيع الحالية - يلزم التحديث يدويًا
  • الإصدارات التي تعمل على Java 6/7: يجب ترقية Java قبل تحديث I2P إلى 2.x
  • فجوات كبيرة بين الإصدارات الرئيسية: حدّث أولًا إلى إصدار وسيط (0.9.47 يُوصى به كنقطة وسيطة)

متى تستخدم المُثبّت مقابل الحزمة:

  • الحزم (apt/yum): الأفضل للخوادم، تحديثات أمنية تلقائية، تكامل مع النظام، إدارة systemd
  • المثبت (.jar): الأفضل للتثبيت على مستوى المستخدم، Windows، macOS، عمليات تثبيت مخصصة، توافر أحدث إصدار

تلف ملف الإعدادات واستعادته

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

الملفات الحرجة وأغراضها:

  • router.keys (516+ bytes): الهوية التشفيرية للـ router - فقدانه يؤدي إلى إنشاء هوية جديدة
  • router.info (يُولَّد تلقائيًا): معلومات الـ router المنشورة - يمكن حذفه بأمان، سيُعاد توليده
  • router.config (نصي): الإعدادات الرئيسية - عرض النطاق الترددي، إعدادات الشبكة، التفضيلات
  • i2ptunnel.config (نصي): تعريفات tunnel (نفق) - tunnels العميل/الخادم، المفاتيح، الوجهات
  • netDb/ (دليل): قاعدة بيانات الأقران - معلومات الـ router الخاصة بمشاركي الشبكة
  • peerProfiles/ (دليل): إحصاءات الأداء عن الأقران - تؤثر على اختيار tunnel
  • keyData/ (دليل): مفاتيح الوجهات لـ eepsites والخدمات - فقدانها يغيّر العناوين
  • addressbook/ (دليل): تعيينات أسماء المضيف .i2p المحلية

إجراء النسخ الاحتياطي الكامل قبل إجراء التعديلات:

# Stop I2P first
i2prouter stop  # or: systemctl stop i2p

# Backup directory
BACKUP_DIR=~/i2p-backup-$(date +%Y%m%d-%H%M)
mkdir -p $BACKUP_DIR

# Copy critical files
cp -r ~/.i2p/router.keys $BACKUP_DIR/
cp -r ~/.i2p/*.config $BACKUP_DIR/
cp -r ~/.i2p/keyData $BACKUP_DIR/
cp -r ~/.i2p/addressbook $BACKUP_DIR/
cp -r ~/.i2p/eepsite $BACKUP_DIR/  # if hosting sites

# Optional but recommended
tar -czf $BACKUP_DIR.tar.gz $BACKUP_DIR

أعراض تلف Router.config:

  • Router لا يبدأ مع وجود أخطاء تحليل في السجلات
  • الإعدادات لا تُحفظ بعد إعادة التشغيل
  • ظهور قيم افتراضية غير متوقعة
  • أحرف مشوهة عند عرض الملف

إصلاح router.config التالف:

  1. أنشئ نسخة احتياطية من الموجود: cp router.config router.config.broken
  2. تحقق من ترميز الملف: يجب أن يكون UTF-8 بدون BOM (علامة ترتيب البايتات)
  3. تحقق من صحة البنية: تستخدم المفاتيح الفاصل = (وليس :)، ومن دون مسافات لاحقة في المفاتيح، و# للتعليقات فقط
  4. أشكال تلف شائعة: أحرف غير ASCII في القيم، ومشكلات في نهايات الأسطر (CRLF مقابل LF)
  5. إذا تعذّر الإصلاح: احذف router.config - سيقوم router بإنشاء إعدادات افتراضية مع الحفاظ على الهوية

إعدادات router.config الأساسية التي ينبغي الحفاظ عليها:

i2np.bandwidth.inboundKBytesPerSecond=512
i2np.bandwidth.outboundKBytesPerSecond=256
router.updatePolicy=notify
routerconsole.lang=en
router.hiddenMode=false

فقدان أو عدم صلاحية router.keys يؤدي إلى إنشاء هوية router جديدة. يُعد هذا مقبولًا ما لم:

  • تشغيل floodfill (عقدة خاصة في I2P لتخزين netDb) (يفقد حالة floodfill)
  • استضافة eepsites (مواقع ويب داخل شبكة I2P) بعنوان منشور (يفقد الاستمرارية)
  • سمعة راسخة في الشبكة

لا يمكن الاستعادة بدون نسخة احتياطية - لإنشاء هوية جديدة: احذف router.keys، وأعِد تشغيل I2P، وسيتم إنشاء هوية جديدة.

تمييز حاسم: router.keys (الهوية) مقابل keyData/* (الخدمات). فقدان router.keys يغيّر هوية router. فقدان keyData/mysite-keys.dat يغيّر عنوان eepsite على .i2p - أمر كارثي إذا كان العنوان منشورًا.

انسخ مفاتيح eepsite/الخدمة احتياطياً بشكل منفصل:

# Identify your service keys
ls -la ~/.i2p/keyData/

# Backup with descriptive names  
cp ~/.i2p/keyData/myservice-keys.dat ~/backups/myservice-keys-$(date +%Y%m%d).dat

# Store securely (encrypted if sensitive)
gpg -c ~/backups/myservice-keys-*.dat

تلف NetDb وpeerProfiles:

الأعراض: عدم وجود أقران نشطين، تعذر إنشاء tunnels، “Database corruption detected” في السجلات

إصلاح آمن (سيقوم الجميع بعملية reseed (إعادة جلب بيانات البداية) و rebuild (إعادة البناء) تلقائياً):

i2prouter stop
rm -rf ~/.i2p/netDb/*
rm -rf ~/.i2p/peerProfiles/*
i2prouter start
# Wait 10-15 minutes for reseed and integration

تحتوي هذه المجلدات على معلومات شبكة مخزنة مؤقتًا فقط - يؤدي حذفها إلى فرض عملية bootstrap (تهيئة أولية) جديدة، دون فقدان أي بيانات حرجة.

استراتيجيات الوقاية:

  1. إيقاف منظّم دائماً: استخدم i2prouter stop أو زر “Shutdown” في لوحة تحكم router - لا تستخدم الإنهاء القسري أبداً
  2. نسخ احتياطية مؤتمتة: مهمة Cron (أداة جدولة مهام في Unix) لنسخ ~/.i2p احتياطياً أسبوعياً إلى قرص منفصل
  3. مراقبة صحة القرص: تحقق دورياً من حالة SMART (تقنية المراقبة الذاتية والتحليل والتبليغ للأقراص) - تعطل الأقراص يفسد البيانات
  4. مساحة قرص كافية: حافظ على توفر أكثر من 1 GB مساحة حرة - امتلاء الأقراص يسبب فساد البيانات
  5. يوصى باستخدام UPS (مزود طاقة غير منقطع): انقطاعات الطاقة أثناء الكتابة تُفسد الملفات
  6. التحكم بالإصدارات للإعدادات الحرِجة: مستودع Git لـ router.config و i2ptunnel.config يتيح التراجع

أذونات الملفات مهمة:

# Correct permissions (user install)
chmod 600 ~/.i2p/router.keys
chmod 600 ~/.i2p/*.config  
chmod 700 ~/.i2p/keyData
chmod 755 ~/.i2p

# Never run as root - creates permission problems

رسائل الخطأ الشائعة مُفسَّرة

يوفّر تسجيل I2P رسائل خطأ محددة تُحدِّد المشكلات بدقة. فهم هذه الرسائل يُسرّع عملية استكشاف الأخطاء وإصلاحها.

تظهر “No tunnels available” عندما لا يكون الـ router قد أنشأ عددًا كافيًا من الـ tunnels للتشغيل. هذا أمر طبيعي خلال أول 5-10 دقائق بعد بدء التشغيل. إذا استمرّ لأكثر من 15 دقيقة:

  1. تحقق من أن عدد النظراء النشطين > 10 على http://127.0.0.1:7657
  2. تحقق من كفاية تخصيص عرض النطاق الترددي (حد أدنى 128+ KB/sec)
  3. افحص معدل نجاح tunnel على http://127.0.0.1:7657/tunnels (يجب أن يكون >40%)
  4. راجع السجلات لمعرفة أسباب رفض إنشاء tunnel

“Clock skew detected” أو “NTCP2 disconnect code 7” يعني أن وقت النظام يختلف عن إجماع الشبكة بأكثر من 90 ثانية. يتطلب I2P دقة ±60 ثانية. يتم رفض الاتصالات مع routers المنحرفة زمنياً تلقائياً.

أصلح فورًا:

# Linux  
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd
date  # Verify correct time

# Windows
# Control Panel → Date and Time → Internet Time → Update now

# Verify after sync
http://127.0.0.1:7657/logs  # Should no longer show clock skew warnings

تعني “Build timeout” أو “Tunnel build timeout exceeded” أن عملية بناء الـ tunnel عبر سلسلة الأقران لم تكتمل ضمن نافذة المهلة الزمنية (عادةً 60 ثانية). الأسباب:

  • أقران بطيئون: اختار Router مشاركين غير مستجيبين لـ tunnel
  • ازدحام الشبكة: شبكة I2P تشهد حملاً مرتفعاً
  • عرض نطاق غير كافٍ: حدود عرض النطاق لديك تمنع بناء tunnel في الوقت المناسب
  • router مُحمَّل بشكل زائد: كثرة tunnels المشاركة تستهلك الموارد

الحلول: زيادة عرض النطاق الترددي، تقليل عدد الـ tunnels (أنفاق I2P) المشاركة (router.maxParticipatingTunnels في http://127.0.0.1:7657/configadvanced)، وتمكين إعادة توجيه المنافذ لتحسين اختيار الأقران.

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

إذا ظل عالقًا في حالة الإيقاف لأكثر من 11 دقيقة، فافرض الإنهاء:

# Linux  
kill -9 $(pgrep -f i2p)

# Windows
taskkill /F /IM javaw.exe

“java.lang.OutOfMemoryError: Java heap space” يشير إلى نفاد ذاكرة الكومة. حلول فورية:

  1. عدّل wrapper.config: wrapper.java.maxmemory=512 (أو أعلى)
  2. مطلوب إيقاف تشغيل كامل - إعادة التشغيل لن تطبق التغيير
  3. انتظر 11 دقيقة لإيقاف التشغيل الكامل
  4. ابدأ router من جديد
  5. تحقق من تخصيص الذاكرة في http://127.0.0.1:7657/graphs - ينبغي أن يُظهر هامشًا احتياطيًا

أخطاء الذاكرة ذات الصلة:

  • “GC overhead limit exceeded”: استغراق وقت طويل في عملية garbage collection (جمع الذاكرة التلقائي) - زِد حجم الـ heap (منطقة الذاكرة المخصصة للكائنات)
  • “Metaspace (مساحة ميتاداتا أصناف Java)”: نَفِدت مساحة بيانات وصف أصناف Java - أضِف wrapper.java.additional.X=-XX:MaxMetaspaceSize=256M

خاص بـ Windows: يحدّ Kaspersky Antivirus كومة Java إلى 512MB بغضّ النظر عن إعدادات wrapper.config - ألغِ التثبيت أو أضِف I2P إلى الاستثناءات.

“انتهاء مهلة الاتصال” أو “خطأ I2CP - المنفذ 7654” عند محاولة التطبيقات الاتصال بالـ router:

  1. تحقق من أن router قيد التشغيل: http://127.0.0.1:7657 يجب أن يستجيب
  2. تحقق من منفذ I2CP: netstat -an | grep 7654 يجب أن يُظهر LISTENING
  3. تأكد من أن جدار الحماية على localhost (المضيف المحلي) يسمح بذلك: sudo ufw allow from 127.0.0.1
  4. تحقق من أن التطبيق يستخدم المنفذ الصحيح (I2CP=7654, SAM=7656)

“Certificate validation failed” أو “RouterInfo corrupt” أثناء reseed (عملية جلب بيانات الشبكة الأولية):

الأسباب الجذرية: انحراف الساعة (أصلح الانحراف أولاً)، تلف في netDb، شهادات reseed (إعادة البذر) غير صالحة

# After fixing clock:
i2prouter stop
rm -rf ~/.i2p/netDb/*  # Delete corrupted database
i2prouter start  # Auto-reseeds with fresh data

“Database corruption detected” تعني حدوث تلف في البيانات على مستوى القرص ضمن netDb أو peerProfiles (ملفات تعريف النظراء):

# Safe fix - all will rebuild
i2prouter stop  
rm -rf ~/.i2p/netDb/* ~/.i2p/peerProfiles/*
i2prouter start

تحقق من صحة القرص باستخدام أدوات SMART (تقنية المراقبة الذاتية والتحليل وإعداد التقارير)؛ إذ إن تكرار تلف البيانات يشير إلى أن وسيط التخزين على وشك الفشل.

التحديات الخاصة بكل منصة

تطرح أنظمة التشغيل المختلفة تحديات فريدة في نشر I2P تتعلق بالأذونات وسياسات الأمان وتكامل النظام.

مشكلات الصلاحيات والخدمات في لينكس

I2P المثبت عبر حزم التوزيعة يعمل تحت حساب نظام i2psvc (Debian/Ubuntu) أو i2p (توزيعات أخرى)، ويتطلب أذونات محددة:

# Fix package install permissions  
sudo chown -R i2psvc:i2psvc /var/lib/i2p /var/log/i2p /run/i2p
sudo chmod 750 /var/log/i2p /var/lib/i2p
sudo chmod 644 /var/lib/i2p/*.config

# User install permissions (should be your user)
chown -R $USER:$USER ~/.i2p
chmod 700 ~/.i2p
chmod 600 ~/.i2p/router.keys ~/.i2p/*.config

حدود واصفات الملفات تؤثر على سعة الـ router للاتصالات. الحدود الافتراضية (1024) غير كافية لـ routers ذات عرض نطاق عالٍ:

# Check current limits
ulimit -n

# Temporary increase  
ulimit -n 4096

# Permanent fix: Edit /etc/security/limits.conf
i2psvc soft nofile 4096
i2psvc hard nofile 8192

# Systemd override
sudo mkdir -p /etc/systemd/system/i2p.service.d/
sudo nano /etc/systemd/system/i2p.service.d/override.conf

# Add:
[Service]
LimitNOFILE=8192

sudo systemctl daemon-reload
sudo systemctl restart i2p

تعارضات AppArmor (آلية أمان في لينكس) الشائعة في Debian/Ubuntu تمنع بدء تشغيل الخدمة:

# Error: "Failed at step APPARMOR spawning /usr/sbin/wrapper"
# Cause: AppArmor profile missing or misconfigured

# Solution 1: Disable AppArmor for I2P
sudo aa-complain /usr/sbin/wrapper

# Solution 2: Reconfigure package without AppArmor
sudo dpkg-reconfigure -plow i2p  
# Select "No" when asked about AppArmor

# Solution 3: LXC/Proxmox containers - disable AppArmor in container config
lxc.apparmor.profile: unconfined

مشكلات SELinux على RHEL/CentOS/Fedora:

# Temporary: Set permissive mode
sudo setenforce 0

# Permanent: Generate custom policy
sudo ausearch -c 'java' --raw | audit2allow -M i2p_policy
sudo semodule -i i2p_policy.pp

# Or disable SELinux for I2P process (less secure)
sudo semanage permissive -a i2p_t

استكشاف أخطاء خدمة SystemD وإصلاحها:

# Detailed service status
sudo systemctl status i2p.service -l

# Full logs  
sudo journalctl -xe -u i2p.service

# Follow logs live
sudo journalctl -f -u i2p.service

# Restart with logging
sudo systemctl restart i2p.service && sudo journalctl -f -u i2p.service

تداخل جدار حماية Windows وبرامج مكافحة الفيروسات

غالبًا ما تقوم Windows Defender ومنتجات مكافحة الفيروسات التابعة لجهات خارجية بالإشارة إلى I2P على أنه مشبوه بسبب أنماط سلوك الشبكة. يمنع الإعداد الصحيح عمليات الحظر غير الضرورية مع الحفاظ على الأمان.

تكوين جدار حماية Windows Defender:

# Run PowerShell as Administrator

# Find Java path (adjust for your Java installation)
$javaPath = "C:\Program Files\Eclipse Adoptium\jdk-11.0.16.101-hotspot\bin\javaw.exe"

# Create inbound rules
New-NetFirewallRule -DisplayName "I2P Java" -Direction Inbound -Program $javaPath -Action Allow
New-NetFirewallRule -DisplayName "I2P UDP" -Direction Inbound -Protocol UDP -LocalPort 22648 -Action Allow  
New-NetFirewallRule -DisplayName "I2P TCP" -Direction Inbound -Protocol TCP -LocalPort 22648 -Action Allow

# Add exclusions to Windows Defender
Add-MpPreference -ExclusionPath "C:\Program Files\i2p"
Add-MpPreference -ExclusionPath "$env:APPDATA\I2P"
Add-MpPreference -ExclusionPath "$env:LOCALAPPDATA\I2P"
Add-MpPreference -ExclusionProcess "javaw.exe"

استبدل المنفذ 22648 بمنفذ I2P الفعلي لديك من http://127.0.0.1:7657/confignet.

مشكلة خاصة بـ Kaspersky Antivirus: تقيّد ميزة “Application Control” لدى Kaspersky ذاكرة Java heap إلى 512MB بغضّ النظر عن إعدادات wrapper.config. يؤدي ذلك إلى OutOfMemoryError (خطأ نفاد الذاكرة) على routers ذات نطاق ترددي مرتفع.

الحلول: 1. أضف I2P إلى قائمة الاستثناءات في Kaspersky: Settings → Additional → Threats and Exclusions → Manage Exclusions 2. أو قم بإلغاء تثبيت Kaspersky (موصى به لتشغيل I2P)

إرشادات عامة لبرامج مكافحة الفيروسات من جهات خارجية:

  • أضِف دليل تثبيت I2P إلى قائمة الاستثناءات
  • أضِف %APPDATA%\I2P و%LOCALAPPDATA%\I2P إلى قائمة الاستثناءات
  • استبعد javaw.exe من التحليل السلوكي
  • عطّل ميزات “Network Attack Protection” التي قد تتداخل مع بروتوكولات I2P

Gatekeeper في macOS يمنع التثبيت

يمنع Gatekeeper في macOS تشغيل التطبيقات غير الموقَّعة. مثبّتات I2P غير موقَّعة باستخدام Apple Developer ID، مما يؤدي إلى ظهور تحذيرات أمنية.

تجاوز Gatekeeper (ميزة أمان في macOS) لمثبّت I2P:

# Method 1: Remove quarantine attribute
xattr -d com.apple.quarantine ~/Downloads/i2pinstall_*.jar
java -jar ~/Downloads/i2pinstall_*.jar

# Method 2: Use System Settings (macOS 13+)
# Try to open installer → macOS blocks it
# System Settings → Privacy & Security → scroll down
# Click "Open Anyway" next to I2P warning
# Confirm in dialog

# Method 3: Control-click installer
# Control-click (right-click) i2pinstall_*.jar
# Select "Open" from menu → "Open" again in dialog
# Bypasses Gatekeeper for this specific file

التشغيل بعد التثبيت قد لا يزال يؤدي إلى ظهور تحذيرات:

# If I2P won't start due to Gatekeeper:
xattr -dr com.apple.quarantine ~/i2p/

لا تقم مطلقًا بتعطيل Gatekeeper بشكل دائم - خطر أمني على التطبيقات الأخرى. استخدم تجاوزات خاصة بكل ملف فقط.

تكوين جدار الحماية في macOS:

  1. تفضيلات النظام → الأمان والخصوصية → جدار الحماية → خيارات جدار الحماية
  2. انقر على “+” لإضافة تطبيق
  3. انتقل إلى تثبيت Java (مثلًا، /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java)
  4. أضِف واضبط على “السماح بالاتصالات الواردة”

مشكلات تطبيق I2P على أندرويد

تفرض قيود إصدارات Android ومحدودية الموارد تحديات فريدة.

المتطلبات الدنيا: - Android 5.0+ (API level 21+) مطلوب للإصدارات الحالية - 512MB RAM كحد أدنى، ويوصى بـ 1GB+ - مساحة تخزين 100MB للتطبيق + بيانات router - يجب تعطيل قيود تشغيل التطبيق في الخلفية لـ I2P

يتعطل التطبيق فورًا:

  1. تحقق من إصدار Android: الإعدادات → حول الهاتف → إصدار Android (يجب أن يكون 5.0+)
  2. أزل تثبيت جميع إصدارات I2P: ثبّت إصدارًا واحدًا فقط:
    • net.i2p.android (Google Play)
    • net.i2p.android.router (F-Droid)
      تؤدي عمليات التثبيت المتعددة إلى تعارض
  3. امسح بيانات التطبيق: الإعدادات → التطبيقات → I2P → التخزين → مسح البيانات
  4. أعد التثبيت من حالة نظيفة

تحسين البطارية يتسبب في إيقاف router:

يقوم Android بإنهاء التطبيقات التي تعمل في الخلفية بشكل عدواني لتوفير طاقة البطارية. يجب استثناء I2P:

  1. الإعدادات → البطارية → تحسين البطارية (أو استخدام بطارية التطبيق)
  2. ابحث عن I2P → عدم التحسين (أو السماح بالنشاط في الخلفية)
  3. الإعدادات → التطبيقات → I2P → البطارية → السماح بالنشاط في الخلفية + إزالة القيود

مشكلات الاتصال على الأجهزة المحمولة:

  • يتطلب التمهيد WiFi: تنزيل reseed (عملية جلب بيانات التهيئة الأولية للشبكة) يستهلك قدراً كبيراً من البيانات - استخدم WiFi وليس الشبكة الخلوية
  • تغييرات الشبكة: لا يتعامل I2P بسلاسة مع تبديل الشبكات - أعد تشغيل التطبيق بعد الانتقال بين WiFi/الشبكة الخلوية
  • عرض النطاق للمحمول: اضبط الإعدادات بشكل متحفظ عند 64-128 KB/sec لتجنب استنزاف البيانات الخلوية

تحسين الأداء للأجهزة المحمولة:

  1. تطبيق I2P → القائمة → الإعدادات → النطاق الترددي
  2. عيّن حدودًا مناسبة: 64 KB/sec وارد، 32 KB/sec صادر للاتصال الخلوي
  3. قلّل عدد tunnels المشاركة: الإعدادات → متقدمة → الحد الأقصى لعدد tunnels المشاركة: 100-200
  4. فعّل “Stop I2P when screen off” للحفاظ على البطارية

التورنت على أندرويد:

  • اقصر عدد التورنتات المتزامنة على 2-3 كحدٍ أقصى
  • قلّل حدة DHT (جدول التجزئة الموزع)
  • استخدم WiFi فقط للتورنت
  • تقبّل سرعات أبطأ على الأجهزة المحمولة

مشكلات إعادة البذر والتمهيد

تتطلب عمليات تثبيت I2P الجديدة reseeding (إعادة البذر) - جلب معلومات الأقران الأولية من خوادم HTTPS عامة للانضمام إلى الشبكة. تؤدي مشكلات reseed إلى عزل المستخدمين بلا أي أقران وبدون إمكانية الوصول إلى الشبكة.

“لا يوجد أقران نشطون” بعد التثبيت الجديد غالبًا ما يشير إلى فشل reseed (عملية الجلب الأولي للأقران). الأعراض:

  • الأقران المعروفون: 0 أو يظل أقل من 5
  • تستمر حالة “Network: Testing” لأكثر من 15 دقيقة
  • تُظهر السجلات “Reseed failed” أو أخطاء اتصال بخوادم reseed (خوادم التزويد الأولي بالأقران)

لماذا يفشل reseed (عملية التمهيد الأولي للشبكة):

  1. حظر HTTPS بواسطة جدار الحماية: جدران حماية الشركات/مزودي خدمة الإنترنت تحظر الاتصالات بخوادم reseed (خوادم تمهيد للشبكة) (المنفذ 443)
  2. أخطاء شهادات SSL: يفتقر النظام إلى شهادات الجذر المحدّثة
  3. اشتراط وكيل (Proxy): تتطلب الشبكة وكيل HTTP/SOCKS للاتصالات الخارجية
  4. انحراف الساعة: يفشل التحقق من شهادات SSL عندما يكون وقت النظام غير صحيح
  5. الرقابة الجغرافية: بعض البلدان/مزودي خدمة الإنترنت يحظرون خوادم reseed المعروفة

فرض إجراء reseed يدوي (جلب بيانات العقد التمهيدية للبدء):

  1. افتح http://127.0.0.1:7657/configreseed
  2. انقر “Save changes and reseed now”
  3. راقب http://127.0.0.1:7657/logs بحثًا عن “Reseed got XX router infos”
  4. انتظر 5-10 دقائق لإتمام المعالجة
  5. تحقّق من http://127.0.0.1:7657 - ينبغي أن يرتفع عدد الأقران المعروفين إلى 50+

قم بإعداد reseed proxy (وكيل لجلب بيانات التمهيد) للشبكات المقيّدة:

http://127.0.0.1:7657/configreseed → إعدادات الوكيل:

  • وكيل HTTP: [proxy-server]:[port]
  • أو SOCKS5: [socks-server]:[port]
  • فعّل “استخدام الوكيل لإعادة البذر فقط”
  • بيانات الاعتماد إذا لزم الأمر
  • احفظ وافرِض إعادة البذر

بديل: وكيل Tor لعملية reseed (استعادة بيانات التمهيد للشبكة):

إذا كان Tor Browser أو Tor daemon قيد التشغيل:

  • نوع الوكيل: SOCKS5
  • المضيف: 127.0.0.1
  • المنفذ: 9050 (منفذ SOCKS الافتراضي في Tor)
  • فعِّل وقم بـ reseed (إعادة البذر)

إعادة البذر يدويًا عبر ملف su3 (كحل أخير):

عند فشل كل إجراءات reseed (عملية جلب نظائر البداية) الآلية، احصل على ملف reseed عبر قناة خارجية:

  1. نزّل i2pseeds.su3 من مصدر موثوق عبر اتصال غير مقيّد (https://reseed.i2p.rocks/i2pseeds.su3 , https://reseed-fr.i2pd.xyz/i2pseeds.su3 )
  2. أوقف I2P بالكامل
  3. انسخ i2pseeds.su3 إلى الدليل ~/.i2p/
  4. ابدأ I2P - سيقوم تلقائيًا باستخراج الملف ومعالجته
  5. احذف i2pseeds.su3 بعد المعالجة
  6. تحقّق من زيادة الأقران على http://127.0.0.1:7657

أخطاء شهادات SSL أثناء إعادة البذر (reseed):

Error: "Reseed: Certificate verification failed"  
Cause: System root certificates outdated or missing

الحلول:

# Linux - update certificates
sudo apt install ca-certificates
sudo update-ca-certificates

# Windows - install KB updates for root certificate trust
# Or install .NET Framework (includes certificate updates)

# macOS - update system
# Software Update includes certificate trust updates

عالِق عند 0 من النُظراء المعروفين لأكثر من 30 دقيقة:

يشير إلى فشل كامل في إعادة البذر. تسلسل استكشاف الأخطاء وإصلاحها:

  1. تحقّق من أن وقت النظام دقيق (أكثر مشكلة شيوعًا - أصلِح هذا أولاً)
  2. اختبر اتصال HTTPS: جرّب الوصول إلى https://reseed.i2p.rocks في المتصفح - إذا فشل، فهذه مشكلة في الشبكة
  3. تحقّق من سجلات I2P على http://127.0.0.1:7657/logs لأخطاء reseed (عملية جلب النظراء الأوّلية) المحددة
  4. جرّب عنوان reseed URL مختلف: http://127.0.0.1:7657/configreseed → أضِف عنوان reseed URL مخصّصًا: https://reseed-fr.i2pd.xyz/
  5. استخدم طريقة ملف su3 اليدوية إذا استُنفِدت المحاولات الآلية

Reseed servers (خوادم إعادة البذر) تتوقف عن العمل أحياناً: يتضمن I2P عدة reseed servers مضمّنة بشكل ثابت. إذا تعطل أحدها، يحاول router غيرها تلقائياً. الفشل التام لجميع reseed servers أمر نادر للغاية لكنه ممكن.

خوادم reseed (خوادم التهيئة الأولية للشبكة) النشطة حاليًا (اعتبارًا من أكتوبر 2025):

أضِفها كعناوين URL مخصّصة إذا واجهت مشاكل مع الإعدادات الافتراضية.

للمستخدمين في المناطق ذات الرقابة المشددة:

فكّر في استخدام Snowflake/Meek bridges (جسور لتخطي الرقابة) عبر Tor لإجراء reseed أولي (التمهيد الأولي لعناوين نظراء I2P)، ثم التحويل إلى I2P مباشرةً بعد الاندماج في الشبكة. أو احصل على i2pseeds.su3 عبر steganography (إخفاء البيانات)، أو البريد الإلكتروني، أو USB من خارج منطقة الرقابة.

متى ينبغي طلب مساعدة إضافية

يغطي هذا الدليل الغالبية العظمى من مشكلات I2P، ولكن بعض المشكلات تتطلب انتباه المطورين أو خبرة المجتمع.

اطلب المساعدة من مجتمع I2P عندما:

  • يتعطّل الـ Router باستمرار بعد اتباع جميع خطوات استكشاف الأخطاء وإصلاحها
  • تسرّبات الذاكرة تتسبب في نمو مطّرد يتجاوز heap (ذاكرة الكومة) المخصّصة
  • يظل معدل نجاح الـ Tunnel أقل من 20% على الرغم من التهيئة الكافية
  • أخطاء جديدة في السجلات لا يغطيها هذا الدليل
  • تم اكتشاف ثغرات أمنية
  • طلبات ميزات أو اقتراحات تحسين

قبل طلب المساعدة، اجمع بيانات التشخيص:

  1. إصدار I2P: http://127.0.0.1:7657 (مثال: “2.10.0”)
  2. إصدار Java: ناتج الأمر java -version
  3. نظام التشغيل والإصدار
  4. حالة الـ router: حالة الشبكة، عدد الأقران النشِطين، tunnels المشاركة
  5. إعدادات عرض النطاق: حدود الوارد/الصادر
  6. حالة إعادة توجيه المنافذ: خلف جدار ناري أو OK
  7. مقتطفات السجل ذات الصلة: آخر 50 سطرًا التي تُظهر الأخطاء من http://127.0.0.1:7657/logs

قنوات الدعم الرسمية:

التوقعات الواقعية مهمة. I2P أبطأ من clearnet (الإنترنت المكشوف) بحكم تصميمه الأساسي - فالـ tunneling المشفّر متعدد القفزات يخلق كموناً متأصلاً. إن I2P router الذي تبلغ أوقات تحميل صفحاته 30 ثانية وتصل سرعات التورنت فيه إلى 50 KB/sec هو يعمل بشكل صحيح، وليس معطلاً. سيُصاب المستخدمون الذين يتوقعون سرعات clearnet بخيبة أمل بغض النظر عن تحسين الإعدادات.

الخلاصة

معظم مشكلات I2P تنبع من ثلاث فئات: نقص الصبر أثناء التمهيد (يتطلب 10-15 دقيقة)، تخصيص موارد غير كافٍ (512 MB RAM، بحد أدنى لعرض النطاق الترددي 256 KB/sec)، أو إعداد غير صحيح لإعادة توجيه المنافذ. إن فهم البنية الموزعة لـ I2P والتصميم الذي يركز على إخفاء الهوية يساعد المستخدمين على التمييز بين السلوك المتوقع والمشكلات الفعلية.

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

عند استكشاف الأخطاء وإصلاحها، تحقّق دائمًا من الأساسيات أولًا: صحة وقت النظام، عرض نطاق ترددي كافٍ، تشغيل الـ router بشكل متواصل، ووجود 10+ نظراء نشطين. تُحل معظم المشكلات عبر معالجة هذه الأساسيات بدلًا من تعديل معلمات تهيئة مبهمة. يكافئ I2P الصبر والتشغيل المستمر بتحسين الأداء مع مرور الوقت، إذ يبني الـ router سمعة ويُحسّن اختيار النظراء على مدى أيام وأسابيع من زمن التشغيل المتواصل.

Was this page helpful?