شغّل عقدتك الخاصة: استخدم مُرحِّل وتخزين Relayium مجانًا

آخر تحديث: 2026-08-06

عمليات النقل عبر الشبكات والروابط المُخزَّنة تستهلك عرض نطاق المُرحِّل والقرص، وهذا يكلّفنا مالًا، لذا تعمل ضمن حصة مجانية وتصبح مدفوعة بعد تجاوزها. هناك طريقة لتفادي ذلك: شغّل عقدتك للترحيل/التخزين، اربطها بحسابك، فتتدفق عمليات نقلك عبر عقدتك بدل عقدتنا — لا شيء يُحسَب، ولا شيء يُفوتَر.

هذا يختلف عن الاستضافة الذاتية لخادم Relayium بالكامل. تبقى تستخدم حساب relayium.com المعتاد ونفس التطبيقات؛ أنت فقط تضيف عقدة تملكها لتحمل حركتك. يأخذك هذا الدليل من جهاز Linux جديد إلى عقدة متصلة في نحو خمس دقائق.

لماذا تشغّل عقدتك الخاصة

سببان. الأول هو التكلفة: عقدة تملكها تحمل حركة مُرحِّلك وتخزينك مباشرة، فلا تلمس أبدًا بنيتنا المحسوبة بالاستهلاك ولا يوجد ما يُفوتَر — استخدامك مجاني مهما كان كبيرًا.

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

ثبّت العقدة وأوصلها إلى الإنترنت

ما تحتاجه قبل الخطوة 1

خادم لينكس يمكن الوصول إليه من الإنترنت — سواء VPS رخيص أو جهاز يعمل دائمًا في البيت. المعماريتان amd64 وarm64 مدعومتان.
صلاحية root على ذلك الخادم، أو sudo. التثبيت يحتاجها مرة واحدة، والعقدة نفسها لا تعمل بصلاحية root أبدًا.
القدرة على فتح المنافذ الواردة — في جدار حماية المضيف، وعلى VPS سحابي في مجموعة الأمان لدى المزوّد أيضًا.
حساب على relayium.com مسجَّل الدخول. أمر التثبيت يُولَّد في صفحة الحساب ويحمل رمزًا صالحًا لمرة واحدة.
مساحة قرص، فقط إن أردت للعقدة أن تخزّن إضافةً إلى الترحيل. العقدة المخصصة للترحيل وحده لا تحتاجها — احذف عندها RELAYIUM_NODE_STORAGE_DIR.

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

سجّل الدخول في relayium.com وافتح صفحة حسابك على ‎/me‎.
انزل إلى «عقدي» واضغط «إضافة عقدة». انسخ أمر التثبيت فورًا — فالرمز الذي بداخله يُعرض مرة واحدة فقط ولا يمكن عرضه ثانيةً.
الصقه على خادمك. سينزّل ثنائي relayium-node ويتحقّق من مجموع التحقّق الخاص به، ويثبّته في ‎/usr/local/bin‎، ويكتب خدمة systemd ويشغّلها.
```
curl -fsSL https://relayium.com/install-node.sh | sudo RELAYIUM_CENTRAL_URL=https://relayium.com RELAYIUM_NODE_TOKEN=<your-token> RELAYIUM_NODE_STORAGE_DIR=/var/lib/relayium-node/blobs sh
```
تأكّد أن الخدمة تعمل وأنها ستعود بعد إعادة التشغيل. الإجابتان كلتاهما مهمّة: active تعني أنها تعمل الآن، وenabled هي ما يصمد أمام إعادة التشغيل.
```
systemctl is-active relayium-node
```
```
systemctl is-enabled relayium-node
```
افتح المنافذ الواردة في جدار حماية المضيف. حالة «متصل» لا تحتاج إلا وصولًا صادرًا، لكن الأقران يرحّلون ويخزّنون عبر هذه المنافذ تحديدًا.
```
sudo ufw allow 3478/udp        # TURN
sudo ufw allow 8081/tcp        # storage
sudo ufw allow 49152:65535/udp # relay
```
على VPS سحابي، اسمح بالمنافذ نفسها في مجموعة الأمان لدى المزوّد كذلك. الاكتفاء بـ ufw يتركها مغلقة في الأعلى، والعقدة تبدو سليمة طوال ذلك الوقت.
عد إلى ‎/me‎ وراقب تحوّل العقدة إلى «متصلة» — عادةً خلال ثلاثين ثانية تقريبًا. ومن حينها تفضّلها عمليات النقل في حسابك تلقائيًا.
اختياري: فعّل «استخدام عقدي وحدها للترحيل والتخزين» ليفشل النقل بدل أن يعود بصمت إلى بنيتنا المشتركة.

كيف تبدو عقدة تعمل بشكل صحيح

يُبلِّغ systemd أن الخدمة active وenabled معًا، وتظهر العقدة «متصلة» تحت «عقدي». وactive وحدها لا تكفي — فالعقدة غير المفعَّلة بـ enabled تختفي عند إعادة التشغيل التالية.

$ systemctl is-active relayium-node
active
$ systemctl is-enabled relayium-node
enabled

الجزء ‎<your-token>‎ يُملأ لك في صفحة الحساب — لا تلصق العنصر النائب أعلاه حرفيًا.
RELAYIUM_NODE_STORAGE_DIR يفعّل تخزين الكتل إضافةً إلى الترحيل. اتركه معطّلًا (احذف المتغير) إن أردت أن تقوم العقدة بالترحيل فقط دون التخزين.
تأكّد من أنه بدأ: systemctl status relayium-node (يجب أن يظهر active/running).
تأكّد من الاستمرارية عبر الإقلاع: systemctl is-enabled relayium-node (يجب أن يظهر enabled).
راقب السجلات مباشرة: journalctl -u relayium-node -f.
المنفذ 3478/udp هو منفذ TURN الذي يستخدمه الأقران للترحيل؛ 8081/tcp هو منفذ HTTP لتخزين الكتل؛ 49152–65535/udp هو نطاق وسائط الترحيل.
على VPS سحابي، اسمح بهذه أيضًا في مجموعة الأمان / جدار حماية الشبكة لدى المزوّد، لا في ufw فقط.

هل تشغيل هذا المثبّت بصلاحية root آمن؟

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

سؤال في محله عن أمرٍ يمرّر سكربتًا من الإنترنت إلى صدفة root، وهو يستحق جوابًا محددًا لا مجرد طمأنة. صلاحية root تُستخدم للتثبيت فقط، ولا تُستخدم في أي شيء تفعله العقدة بعد ذلك. يُنشئ المثبّت حسابًا نظاميًا اسمه relayium-node بلا صدفة دخول وبلا مجلد منزل، ويكتب وحدات systemd، ويشغّل الخدمة، ثم ينتهي. أما العقدة نفسها فلا تعمل بصلاحية root أبدًا: وحدتها تضبط User=relayium-node، فمنذ اللحظة التي تتصل فيها هي حساب غير مُمتاز لا يملك شيئًا آخر على جهازك. (التحديث التلقائي، وهو مفعّل افتراضيًا، يضيف بالفعل وحدة ثانية تعمل بصلاحية root — والقسم التالي مخصص بالكامل لما تستطيع تلك الوحدة فعله وما لا تستطيعه.)

وحول هذا الحساب تضع الوحدة صندوق عزل من systemd. كل سطر فيه موجَّه إلى شيء قد يمدّ إليه مهاجمٌ يده لو استولى يومًا على عملية العقدة. ولا شيء هنا مخفيّ عنك: بعد التثبيت اقرأ الوحدة كاملة بـ cat /etc/systemd/system/relayium-node.service.

في الوحدة	ما الذي يمنعه إن اختُرقت العقدة يومًا
`User=relayium-node`	المهاجم مجرد مستخدم لا يملك شيئًا، وليس root.
`ProtectHome=yes`	‏/home و /root غير مرئيين — لا مفاتيح SSH خاصة ولا بيانات مشاريع أخرى.
`ProtectSystem=strict`	نظام الملفات كله للقراءة فقط؛ لا يمكن تعديل أي ملف نظام.
`ReadWritePaths=`	المواضع الوحيدة القابلة للكتابة هي مجلد حالة العقدة نفسها، ومجلد التخزين إن أعددت واحدًا. وأي كتابة في مكان آخر تفشل.
`NoExecPaths=`	لا شيء في مجلد التخزين قابل للتنفيذ — الملف المرفوع لا يمكن تشغيله.
`NoNewPrivileges=yes`	لا طريق للعودة إلى root؛ حيل تصعيد الصلاحيات المعتادة مغلقة.
`CapabilityBoundingSet=`	فارغة — لا قدرات Linux على الإطلاق.
`ProtectKernelTunables=yes، ProtectKernelModules=yes`	النواة بعيدة المنال: لا تغيير لـ sysctl، ولا تحميل وحدات، ولا زرع rootkit.

لا يشير ReadWritePaths وNoExecPaths إلى مجلد التخزين إلا على عقدة تخزّن فعلًا. أما العقدة المخصصة للترحيل فقط فلا يظهر لديها أيٌّ من السطرين، ولا تستطيع الكتابة في أي مكان سوى مجلد حالتها.
مجموعة القدرات فارغة في الحالة المعتادة. والاستثناء الوحيد هو مستمع التنزيل المباشر على منفذ أقل من 1024، إذ يحتاج CAP_NET_BIND_SERVICE للارتباط به؛ ومنفذ التنزيل الافتراضي هو 2053، أي فوق 1024، فلا يُمنح شيء.
العقدة لا تحمل أي مفاتيح. تُشفَّر الملفات لدى المرسِل قبل رفعها، فما يصل إلى عقدة التخزين نصٌّ مُشفَّر لا تستطيع قراءته — بما في ذلك عقدتك أنت، وبما في ذلك أنت شخصيًا.

ما الذي يستطيع المحدِّث التلقائي فعله وما لا يستطيعه

يُعِدّ المثبّت أيضًا مؤقّت تحديث ذاتي، مفعّلًا افتراضيًا: يسأل relayium-node-update.timer موقع relayium.com كل عشر دقائق تقريبًا عن الإصدار الذي ينبغي أن تشغّله هذه العقدة. هذه وحدة ثانية، وهي تعمل بصلاحية root، لذا فهي مدينة لك بشرحٍ خاص بها.

المركز لا يرسل ثنائيًا أبدًا. جوابه كله رقم إصدار، وعلَمان (هل يجوز لهذه العقدة أن تنتقل الآن، وهل هذا تخفيضٌ متعمَّد للإصدار) وسطر قصير يوضّح السبب — لا بايتات ولا رابط ولا أمر. بعدها تجلب العقدة ذلك الإصدار بنفسها، وتقارن SHA-256 للأرشيف بملف checksums.txt الخاص بالإصدار، ثم تتحقق من توقيع ECDSA P-256 على ذلك الملف باستخدام مفتاح عام مُضمَّن داخل الثنائي نفسه الذي يجري التحقق. والنصف الخاص من هذا المفتاح ليس على الخادم الذي يجيب عن هذه الاستعلامات. فحتى لو اختُرق المركز، فأقصى ما يستطيعه هو تسمية إصدار؛ ولا يستطيع صناعة ثنائي يجتاز التحقق.

المحدِّث والعقدة عمليتان منفصلتان بصلاحيتين متعاكستين. فـ relayium-node.service هو صندوق العزل الموصوف أعلاه — وتحت ProtectSystem=strict لا يستطيع الكتابة في /usr/local/bin إطلاقًا، أي أن العقدة لا تستطيع أبدًا تعديل أي ثنائي، بما فيه ثنائيها هي. أما relayium-node-update.service فهو وحدة oneshot صغيرة تعمل بصلاحية root ولا تحمل صندوق عزل عن قصد، لأن استبدال ملف في /usr/local/bin يتطلب بالضبط تلك الصلاحية التي وُجد صندوق عزل العقدة كي يمنعها عنها. وحصر هذه القدرة في وحدة واحدة أحادية الغرض، بدل إرخاء تحصين العقدة نفسها، هو مغزى هذا الفصل كله: العملية التي تملك root لا تفعل شيئًا سوى تبديل الثنائيات، والعملية الحبيسة لا تستطيع أن تمسّ ثنائيًا أبدًا.

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

إن لم ترده: أعد تشغيل المثبّت مع RELAYIUM_NODE_AUTO_UPDATE=off. عندها يُعطَّل المؤقّت وخدمته ويُحذفان؛ وتستمر العقدة في العمل، وتحدّثها أنت متى شئت.
إن انتهيت من العقدة تمامًا: انظر «إزالة عقدتك» أدناه.

إزالة عقدتك

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

نزّله وتحقّق منه ثم شغّله. تمريره مباشرة إلى sh يعني أن خطأ 404 أو انقطاعًا عابرًا في الشبكة سيجعل الأمر كله لا يطبع شيئًا وينتهي برمز 0، وهو ما يبدو كإلغاء ناجح.

لا يزيل إلا ما يعرفه: أي شيء غير متوقع في دليل الحالة أو دليل التخزين يُحتفظ به ويُبلَّغ عنه بدل حذفه.

curl -fsSL https://relayium.com/uninstall-node.sh -o uninstall-node.sh && \
  [ -s uninstall-node.sh ] && sudo sh uninstall-node.sh

يرفض ما دام دليل التخزين يحوي أي ملف لا يعرفه — بما في ذلك كائن منتهي الصلاحية لم يصله التنظيف بعد — لأن كل ملف مخزَّن يوجد على عقدة واحدة فقط ولا توجد نسخ. انتظر حتى يصل العدد إلى صفر، أو مرّر RELAYIUM_NODE_FORCE=1 قابلًا بأن تصبح تلك الملفات غير قابلة للوصول.
إن تعذّر عليه تحديد مكان الكائنات، يتوقف بدل أن يخمّن. المتغير RELAYIUM_NODE_ASSUME_NO_STORAGE=1 هو السبيل الوحيد لتجاوز ذلك، ومع هذا لا يحذف شيئًا لا يعرفه.
يبقى دليل التخزين نفسه ما لم تمرّر أيضًا RELAYIUM_NODE_PURGE_STORAGE=1. متغيرات البيئة لا تعبر | sudo sh — مرّرها هكذا: sudo env RELAYIUM_NODE_PURGE_STORAGE=1 sh uninstall-node.sh.
بعد ذلك يجب أن يقول systemctl status relayium-node أنه not-found وألا يظهر أي مؤقّت relayium-node. وإذا أعدت التثبيت لاحقًا فستحصل في حسابك على عقدة جديدة تمامًا: فالإلغاء يحذف ملف هوية العقدة، لذا يسجّل التثبيت الجديد عقدة جديدة بدل إحياء القديمة.

حين لا ينجح الأمر

خمسة إخفاقات تغطي تقريبًا كل عقدة لا تقلع، وثلاثة منها تبدو سليمة من جهة الخادم: الخدمة تعمل، ولا يخبرك بغير ذلك إلا صفحة الحساب أو مقبس مُنصِت.

العَرَض، الفحص، الإصلاح

تردّ الصدفة بـ «relayium-node: command not found».

command -v relayium-node
# لا شيء يُطبع

الثنائي غير مثبَّت. ولا يُثبَّت relayium-node منفصلًا أبدًا — فأمر السطر الواحد في صفحة الحساب هو ما ينزّله ويضعه في مسار PATH ويشغّله كخدمة. شغّل ذلك الأمر بدلًا من هذا.

الخدمة active لكن العقدة لا تصير «متصلة» في صفحة الحساب أبدًا.

journalctl -u relayium-node -n 50 --no-pager

حالة «متصل» يقرّرها نبض صادر، لذا نادرًا ما يكون جدار الحماية هو السبب هنا — بل التسجيل. الرمز صالح لمرة واحدة، فيفشل أمر سبق تشغيله أو أمر قديم بقي من محاولة سابقة. اضغط «إضافة عقدة» مجددًا للحصول على أمر جديد وأعد تشغيله.

العقدة تظهر «متصلة» ومع ذلك تمر عمليات النقل عبر بنيتنا المشتركة.

sudo ss -lunp | grep 3478

«متصل» لا تثبت إلا النبض الصادر. ما يحتاجه الأقران هو المنافذ الواردة: تأكّد أن العقدة تُنصِت، ثم افتح 3478/udp و8081/tcp و49152-65535/udp في جدار حماية المضيف وفي مجموعة الأمان السحابية معًا. ولاستبعاد أي عودة صامتة تمامًا، فعّل إعداد الاقتصار على عقدك.

أمر الإزالة لم يطبع شيئًا وانتهى بالرمز 0، والخدمة ما تزال موجودة.

systemctl status relayium-node
# active (running)

هذا بالضبط شكل تمرير تنزيل فاشل إلى sh: خطأ 404 أو انقطاع عابر في الشبكة لا يطبع شيئًا وينتهي بالرمز 0، فيُقرأ كنجاح. نزّل السكربت، وتحقّق أنه ليس فارغًا، ثم شغّله — ولهذا كُتب الأمر في هذا الدليل على ثلاثة أجزاء لا كأنبوب واحد.

الإزالة ترفض ما دام دليل التخزين يحوي ملفات.

sudo ls /var/lib/relayium-node/blobs | wc -l

هذا مقصود. فكل ملف مخزَّن يوجد على عقدة واحدة بالضبط ولا نسخ احتياطية له، وإزالة العقدة تجعل تلك الملفات غير قابلة للوصول. انتظر حتى يبلغ العدد صفرًا مع انتهاء صلاحية الكتل، أو اقبل الخسارة بـ RELAYIUM_NODE_FORCE=1. ومتغيرات البيئة لا تعبر أنبوبًا إلى sudo sh، فمرّرها بصيغة sudo env RELAYIUM_NODE_FORCE=1 sh uninstall-node.sh.

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

ظهر لي «‎relayium-node: command not found‎» — ما الخطأ؟

لقد شغّلت ثنائي relayium-node قبل تثبيته. استخدم أمر التثبيت ذا السطر الواحد من صفحة الحساب (بصيغة curl … | sudo … sh): إنه ينزّل الثنائي، ويضعه في مسار PATH، ويشغّله كخدمة. أنت لا تثبّت relayium-node بشكل منفصل أبدًا.

هل تبقى العقدة متصلة بعد إعادة التشغيل؟

نعم. يسجّل المثبّت خدمة systemd مُفعَّلة عند الإقلاع ومضبوطة على Restart=always، فتعود بعد إعادة التشغيل وتعيد تشغيل نفسها إذا تعطّلت. لا شيء إضافي لتشغيله.

كيف يختلف هذا عن الاستضافة الذاتية لـ Relayium؟

تشغيل عقدتك الخاصة يبقي حساب relayium.com المعتاد وتطبيقاتك ويضيف فقط عقدة تملكها لتحمل حركتك. أما الاستضافة الذاتية فتشغّل حزمة الخادم بالكامل (الحسابات، تطبيق الويب، الإشارة) على نطاقك الخاص — راجع دليل «الاستضافة الذاتية لـ Relayium» لذلك.

هل يمكن لأي شخص آخر استخدام عقدتي أو رؤية بياناتي؟

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

سجّل الدخول، افتح صفحة حسابك، وأضف عقدتك الأولى في أقل من دقيقة.

افتح صفحة الحساب