اكتشاف العُقد والترحيل المشفّر متعدد القفزات

تجد عُقد AeroNyx بعضها بعضًا عبر واصفات موقّعة ذات صلاحية محدودة، ويمكنها تمرير حمولات مشفّرة من طرف إلى طرف قفزةً تلو قفزة، بحيث لا يزيل كل مُرحِّل إلا طبقة التشفير الخاصة به. واليوم، تمر الدردشة الفعلية للمستخدمين افتراضيًا عبر مُرحِّل AeroNyx المركزي (RelayWS). أما توجيه الدردشة عبر العُقد فهو إعداد اختياري في التطبيق.

ما يعمل اليوم

المسارات المركزية واللامركزية تعمل جنبًا إلى جنب.

كيف يعمل الاكتشاف

تنشر كل عقدة واصفًا موقّعًا بمفتاح هوية Ed25519 الخاص بها. يتضمن الواصف معرّف العقدة، وأوقات الإصدار وانتهاء الصلاحية، ونقطة نهاية عامة اختيارية، وأعلام القدرات (مثل المُرحِّل البصلي الوسيط أو مُرحِّل الدردشة)، وتلميحات تقريبية عن السعة، والمفتاح المستخدم للتشفير البصلي. وترفض العُقد الواصفات المنتهية الصلاحية أو التي تحمل توقيعًا غير صالح.

• تبادل المعلومات محدود. تبادل الأقران خاضع لحدود المعدّل ومشروط بالسياسة، وللرسائل حدود في الحجم.
• الاستعادة بعد إعادة التشغيل. تحتفظ العقدة بذاكرة تخزين مؤقت محلية للأقران، وتعود إلى نقاط النهاية الأولية المُهيَّأة بعد إعادة التشغيل. ويمكن للمشغّلين أيضًا تثبيت نقاط البداية.
• اختيار المسار. لا تُعدّ مرشّحة للترحيل إلا الواصفات الحديثة التي تتضمن نقطة نهاية قابلة للاستخدام ومفتاحًا بصليًا.

نقاط النهاية التي يجوز للواصف تسميتها

يثبت التوقيع من نشر الواصف، لكنه لا يثبت أن نقطة النهاية فيه آمنة للاتصال. لذا لا تقبل العقدة إلا صيغتين لنقطة النهاية:

• عنوان IP عام عبر http أو https؛ وتُرفض نطاقات الاسترجاع (loopback) والنطاقات الخاصة ونطاقات الربط المحلي وCGNAT ونطاقات التوثيق والبث المتعدد والنطاقات المحجوزة؛
• عنوان URL بصيغة https:// باسم DNS عام. وتُرفض الأسماء أحادية المقطع وlocalhost واللواحق الخاصة مثل .local و.internal و.home.arpa.

تُحَلّ أسماء المضيفين وقت الاتصال عبر خادم حلّ يُسقط كل عنوان غير عام، لذا لا يمكن توجيه اسم إلى العقدة نفسها أو إلى شبكة خاصة أو إلى خدمة بيانات وصفية سحابية. كما يتجاهل عملاء الأقران إعدادات الوكيل (proxy) ولا يتبعون عمليات إعادة التوجيه أبدًا.

توجد صيغة اسم المضيف لكي تتمكن العُقد التي لا تملك عنوان IP خاصًا بها، مثل عقدة TEE خلف بوابة سحابية، من المشاركة.

نقاط البداية المثبّتة

العقدة التي تبدأ دون لقطة من المشغّل لا تثق إلا بالهويات التي تملكها بالفعل، فقد ينتهي بها الأمر إلى الوثوق بنفسها فقط. وفي هذه الحالة يستطيع المشغّل تسمية الهوية المتوقعة عند عنوان معيّن:

[discovery]
pinned_seeds = ["<64-hex node id>@<public ip>:<port>"]

• لا تُقبل الهوية المثبّتة للمرة الأولى إلا بعد تبادل عبر TLS المرتبط بالهوية مثبّت على تلك الهوية.
• كل واصف لاحق لهوية مثبّتة، من أي مصدر، يجب أن يحتفظ بالعنوان المثبّت وأن يعلن عن TLS المرتبط بالهوية.
• الثقة لا تنتقل: تبقى الواصفات الأخرى في ردّ نقطة البداية مرشّحات غير موثوقة.
• لا يمكن لتثبيت أُزيل أن يعود من ذاكرة تخزين مؤقت قديمة أو من نسخة احتياطية.

Directory Chain

تحتفظ كل عقدة أيضًا بتاريخ موقّع ومترابط بالتجزئة لأحداث واصفها، يُسمّى Directory Chain الخاصة بها. يمكن للعُقد الأخرى عكس ذلك التاريخ، وجلب كائنات الواصفات، وطلب إثباتات تضمين لواصف معيّن. ويمكن للأقران الذين يثبّتهم المشغّل توقيع نقاط تحقق رصدية على التواريخ التي رأوها.

لا يوجد سجل عالمي ولا منسّق واحد: كل عقدة توقّع تاريخها الخاص، والعُقد الأخرى تعكسه وتتحقق منه.

TLS المرتبط بالهوية

الوصول إلى عقدة عبر HTTPS يحتاج عادةً إلى اسم نطاق وإلى شهادة من سلطة شهادات، ومعظم عُقد AeroNyx لا يمكن الوصول إليها إلا بعنوان IP. وبدلًا من ذلك، تثبت العقدة نقطة نهاية HTTPS الخاصة بها بهوية Ed25519 الخاصة بها.

• كيف يعمل. تنشئ العقدة مفتاح TLS عاديًا من نوع ECDSA P-256 وشهادة موقّعة ذاتيًا. يحمل أحد الأسماء البديلة للموضوع ربطًا هو aeronyx-tls-binding:v1:<node id>:<expiry>:<signature>، حيث يصنع مفتاحُ هوية العقدة التوقيعَ على ملخّص منفصل النطاق للمفتاح العام للشهادة نفسها ومعرّف العقدة وتاريخ الانتهاء. ويثبت تبادل TLS 1.3 أن العقدة تملك مفتاح الشهادة. ولا يوقّع مفتاح الهوية أي تبادل أبدًا.
• ما يتحقق منه العميل. لا يقبل المتحقِّق شهادةً إلا للعقدة التي قصد الوصول إليها: ربط واحد فقط، ومعرّف العقدة المتوقع، وغير منتهية الصلاحية، وتبقّى لها 31 يومًا من الصلاحية على الأكثر، وتوقيع صالح على مفتاح هذه الشهادة. والشهادة الصادرة عن سلطة شهادات لا تستوفي هذا الفحص.
• المنفذ نفسه. يخدم منفذ واجهة API العامة (8422/TCP) الاثنين معًا: الاتصال الذي يبدأ بتبادل TLS يحصل على TLS، وأي اتصال آخر يحصل على HTTP عادي كما في السابق. وهو مفعّل افتراضيًا (discovery.public_api_identity_tls).
• بين العُقد. العقدة التي يعلن واصفها الموقّع عن ميزة البروتوكول anpf1-ibt1 تقدّم TLS المرتبط بالهوية. والنظير الذي يرى هذه الميزة يجب أن يصل إلى تلك العقدة عبر TLS مثبّت على هويتها، ولا يعود أبدًا إلى HTTP العادي. ويشمل توقيعُ الواصف هذه الميزة، لذا لا يستطيع مهاجم في الشبكة إزالتها لفرض خفض المستوى. وإذا ادّعت عدة هويات نقطة النهاية نفسها، لا يُنتَج عنوان TLS ويفشل الطلب بإغلاق آمن. أما العُقد الأقدم التي لا تملك الميزة، ونقاط نهاية البوابات المسمّاة بـ DNS، فتحتفظ بسلوكها السابق.
• المرجع. المصدر ومتجهات الاختبار المجمّدة: aeronyx-node-tls.

النتيجة أن معلومات المسار في القفزات البصلية، وتبادل المعلومات، ومزامنة الدليل، وحركة الشهود بين العُقد لم تعد مقروءة على الشبكة. ودعم التطبيق للاتصال بالعُقد بهذه الطريقة قيد التطوير.

كيف يعمل الترحيل متعدد القفزات

1. يغلّف المرسل الحمولة بطبقة تشفير واحدة لكل قفزة، باستخدام المفتاح البصلي المنشور لكل مُرحِّل.
2. يتحقق كل مُرحِّل من توقيع القفزة السابقة وطابعها الزمني وحالة منع إعادة الإرسال، ويزيل طبقته، ويمرّر الكتلة المعتمة المتبقية. ولا يرى الطبقات الداخلية أبدًا.
3. تسلّم العقدة النهائية (الطرفية) الرسالة إلى صندوق وارد المُرحِّل لدى المستلم (المُرحِّل المركزي افتراضيًا)، ولا تعيد إيصالًا موقّعًا إلا بعد أن يقبلها المُرحِّل. يربط الإيصال معرّف المسار، والتزامًا تجاه الحمولة، وهوية العقدة الطرفية، ووقت التسليم. وهو يثبت أن الرسالة قُبلت في عهدة المُرحِّل، لا أن المستلم قرأها. أما العقدة التي عُطّل فيها التسليم فتحتفظ بالرسالة في مخزنها وتوقّع إيصالًا من النوع نفسه، لذا لا يميّز الإيصال وحده بين الحالتين.

ما يراه كل طرف

لا توجد عقدة واحدة تربط عنوان شبكتك بمن تكتب إليه. فالعقدة الطرفية والمُرحِّل المركزي كلتاهما ترى من كتب إلى من.

يقبل البروتوكول ثلاث قفزات ترحيل متحقَّق منها كحد أقصى. ويستخدم مسار الخصوصية في التطبيق قفزتين. وحدود منع إساءة الاستخدام على المُرحِّلات موصوفة في حارس إساءة الاستخدام للمُرحِّل الأعمى.

الدردشة في التطبيق

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

أحجام سحب صندوق البريد المجهول

كانت نتيجة سحب صندوق البريد صورة ثابتة واحدة بحجم 163,130 بايت أيًّا كان العنصر، فكانت الرسالة القصيرة تكلّف استجابة بنحو 160 KiB. أما الإصدار 2 من السحب، المتفاوَض عليه عبر ميزة البروتوكول الموقّعة anpf1-ampc1، فيحشو العنصر المختوم إلى أصغر فئة من خمس فئات حجم (4,204 أو 16,492 أو 65,644 أو 131,180 بايت، أو الحد الأقصى للترميز). وأصبح عنصر بحجم 4,096 بايت يُنقل الآن بحجم 4,518 بايت.

عقدة TEE

تعمل عقدة إنتاج واحدة داخل بيئة تنفيذ موثوقة على Phala Cloud (dstack على Intel TDX). وهي لا تعمل إلا بوصفها صندوق بريد مجهولًا ومُرحِّلًا بصليًا: VPN فيها معطّل، وMemChain معطّل، ويأتي مفتاح هويتها من خدمة مفاتيح dstack. ولا يمكن الوصول إليها إلا عبر اسم مضيف TLS على البوابة، ولهذا أُضيفت نقاط النهاية بأسماء المضيفين. ولا يتحقق التطبيق حاليًا من إثبات TEE الخاص بالعقدة.

الحالة الحية

تُنشر حالة الشبكة المجمّعة على:

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

تظهر مجاميع الترحيل والاكتشاف ضمن data.protocol_status، على سبيل المثال peer_store.blind_relay وpeer_store.peer_quorum. لاحظ نقطتين عند قراءتها:

• لا تحتسب المجاميع على مستوى العُقد إلا العُقد التي لديها نبضة خلال آخر 120 ثانية، لذا تخرج العقدة غير المتصلة من أعداد مثل protocol_status.reported_nodes. أما network.total_nodes وnetwork.vpn_nodes فلا تزالان تحسبان العُقد النشطة المسجّلة، سواء أكانت متصلة أم لا.
• عدّادات المسبار الاصطناعية (probe_*، two_hop_probe_*) تقيس سلامة المسارات. وهي ليست حركة مرور للمستخدمين.

لا تتضمن الاستجابة العامة إلا أعدادًا وفئات حالة وطوابع زمنية. ولا تتضمن أبدًا معرّفات العُقد أو نقاط النهاية أو معرّفات المسارات أو الحمولات أو المستلمين أو عناوين IP للعملاء أو بيانات DNS أو روابط الرسم البياني الاجتماعي. راجع إحصاءات الشبكة وحدود الخصوصية.

الأسئلة الشائعة

هل تمر رسائل الدردشة الخاصة بي في AeroNyx عبر عُقد لامركزية؟

ليس افتراضيًا. تمر الرسائل عبر خدمة RelayWS المركزية. يمكنك تفعيل مسار الخصوصية في التطبيق، الذي يرسل الرسائل الفردية عبر مسار بصلي من قفزتين بين العُقد عندما يكون جاهزًا. وإذا لم يقبل أي مسار رسالةً ما، يحتفظ بها التطبيق حتى يتوفر مسار أو توافق على إرسال تلك الرسالة عبر المُرحِّل القياسي.

هل تستطيع عقدة الترحيل قراءة الرسائل التي تمرّرها؟

لا. لا يزيل المُرحِّل إلا طبقة التشفير الخاصة به ويمرّر كتلة معتمة. كما أن محتوى الرسائل مشفّر من طرف إلى طرف بين الأشخاص المشاركين في المحادثة.

ما هي Directory Chain؟

Directory Chain هي تاريخ كل عقدة الموقّع والمترابط بالتجزئة لواصفاتها. تعكسها العُقد الأخرى ويمكنها طلب إثباتات التضمين. وليس لها منسّق عالمي.

كيف يمكن لعقدة خلف بوابة الانضمام إلى الشبكة؟

يمكنها نشر اسم مضيف بصيغة https:// بوصفه نقطة النهاية الخاصة بها. تحلّ العُقد الأخرى ذلك الاسم وقت الاتصال ولا تستخدم إلا العناوين العامة، لذا لا يمكن إعادة توجيه الاسم إلى أهداف خاصة أو داخلية.

لماذا تعرض صفحة الإحصاءات العامة عُقدًا مسجّلة أكثر من العُقد المتصلة؟

تحسب network.total_nodes وnetwork.vpn_nodes العُقد النشطة المسجّلة سواء أكانت متصلة أم لا. قارنهما بـ network.online_vpn_nodes. أما أعداد البروتوكول والترحيل فلا تشمل إلا العُقد ذات النبضات الحديثة.

هل تحتاج العُقد إلى اسم نطاق أو سلطة شهادات لاستخدام HTTPS؟

لا. تستطيع العقدة إثبات نقطة نهاية HTTPS الخاصة بها بمفتاح هويتها: تحمل شهادة TLS الخاصة بها توقيعًا من هوية العقدة على مفتاح الشهادة، ويمكن للعميل أو النظير الذي يعرف معرّف العقدة التحقق منه. ويمكن للعُقد الواقعة خلف بوابة أن تستخدم بدلًا من ذلك اسم مضيف https://.

ماذا يثبت إيصال التسليم الموقّع؟

يثبت أن العقدة الطرفية قبلت الرسالة في عهدة المُرحِّل، أي عمليًا في صندوق وارد المُرحِّل لدى المستلم. ولا يثبت أن المستلم رآها أو قرأها. لذلك استخدم إيصالات التسليم والقراءة في بروتوكول الدردشة.