النقل من خادم إلى خادم باستخدام واجهة Relayium الطرفية (daemon direct)

آخر تحديث: 2026-09-01

حين يكون الجهازان كلاهما لك ويعرف كلٌّ منهما عنوان الآخر، يصبح SSH احتكاكًا زائدًا والتعارف عبئًا محضًا. صُمِّم daemon direct لهذا تمامًا: خادم يُنصِت، والآخر يدفع إليه مباشرةً عبر اتصال TLS 1.3 مُثبَّت. لا مُرحِّل، لا SSH، لا رمز اقتران — الثقة تقوم على المفتاح العام وتُهيَّأ مرةً واحدة.

يغطي هذا الدليل تشغيل المُستمِع، والدفع إليه، واعتماد مُرسِل جديد عند أول اتصال، وأتمتة ذلك، وتشغيل المُستمِع كخدمة systemd.

قبل أن تبدأ

كل ما يلي هو relayium CLI، فثبّته أولًا إن لم تكن قد فعلت. على macOS وLinux، يُسقط أمر واحد ملفًا ثنائيًا مُسبق البناء في PATH الخاص بك:

curl -fsSL https://relayium.com/install.sh | sh

تفضّل اختيار الملف بنفسك، أو تعمل على Windows؟ احصل على ملف ثنائي من صفحة الإصدارات — يسرد relayium.com/cli كل خيارات التثبيت (أو go build -o relayium ./cmd/relayium إن كان لديك Go).
يؤكّد relayium --version أنه مثبَّت. تخطَّ هذا وستطبع الأوامر أدناه ‘command not found’ لا غير.

شغّل المُستمِع (على المُستقبِل)

ما تحتاج إليه

جهازان تتحكم بهما، وعنوان المُستقبِل قابل للوصول من المُرسِل. يصلح اسم مضيف أو عنوان IP مجرد.
برنامج relayium على الطرفين. لا يتحدث daemon direct إلا البروتوكول الأصلي، فلا يوجد هنا تراجع إلى tar ينقذ تثبيتًا ناقصًا.
منفذ المُستمِع مفتوح أمام المُرسِل، وهو 9031/TCP ما لم تغيّره، في جدار حماية المضيف وفي أي مجموعة أمان سحابية.
طرفية على المُستقبِل من أجل أول دفعة، كي تجيب عن سؤال الاعتماد. وإن لم تكن هناك طرفية، فاعتمِد المُرسِل مسبقًا بدلًا من ذلك (انظر أدناه).

على الخادم المُستقبِل، يستمع serve للدفعات ويكتبها في مجلد. يعمل باستمرار افتراضيًا؛ أضِف --once لقبول نقلة واحدة ثم الخروج. لا تشارك أي شيء مسبقًا — لا بصمات تنسخها سلفًا:

أنشئ المجلد الذي يجب أن تصل إليه الدفعات.
```
mkdir -p ~/inbox
```
لا تفتح منفذ المُستمِع إلا أمام المُرسِل. استبدِل 203.0.113.7 بعنوان المُرسِل نفسه — عنوانه العام، أو الخاص إن كان الخادمان على الشبكة ذاتها — وضيِّق مجموعة الأمان السحابية على المصدر نفسه بدل فتحها للإنترنت كله.
```
sudo ufw allow from 203.0.113.7 to any port 9031 proto tcp
```
شغّل المُستمِع في طرفية، كي يكون هناك من يجيب عن سؤال الاعتماد عند أول دفعة. أضِف --once ليأخذ نقلة واحدة ثم يخرج، أو --port لنقله عن 9031.
```
relayium serve --dir ~/inbox
```

كيف يبدو مُستمِع يعمل

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

relayium serve --dir ~/inbox
no authorized peers yet — you'll be asked to approve each new peer on its first push.
relayium serve: listening on [::]:9031, receiving into /home/you/inbox (fingerprint 5c1d9f04…)

يعالج المُستمِع الاتصالات واحدًا تلو الآخر ويُنزِل الملفات تحت --dir.
المنفذ الافتراضي هو 9031؛ غيّره بـ --port وافتحه على جدارك الناري.

ادفع إليه (على المُرسِل)

من الخادم المُرسِل، ادفع إلى عنوان relayium:// الخاص بالمُستقبِل. يُثبِّت الاتصال الأول بصمة المُستقبِل؛ ويتحقق منها كل اتصال بعده، وتُرفَض البصمة المتغيّرة بدل قبولها بصمت — فالمفتاح المُستبدَل أو هجوم الوسيط يُكتشَف، لا يُوثَق به. عند أول دفعة على الإطلاق، ينتظر المُرسِل لحظةً بينما يعتمده المُستقبِل (الخطوة التالية).

نفّذ الدفع على الخادم المُرسِل. في أول اتصال على الإطلاق يتوقف هنا بالضبط ريثما يعتمده المُستقبِل.
```
relayium push ./build.tar.zst relayium://receiver.example.com
```
أجِب عن السؤال على المُستقبِل، وهو موضوع القسم التالي. بعدها تكتمل الدفعة وحدها، ولن تتوقف الدفعات اللاحقة هنا أبدًا.
أضِف منفذًا في نهاية العنوان حين لا يكون المُستمِع على 9031.
```
relayium push ./build.tar.zst relayium://receiver.example.com:9040
```

كيف تبدو دفعة ناجحة

عند أول اتصال يتعلّم المُرسِل بصمة المُستمِع ويثبّتها، ثم ينقل. ويسجّل المُستقبِل بصمة الدافع ويُبلِغ بعدد الملفات والبايتات.

# on the SENDER, first contact
learned receiver.example.com:9031 5c1d9f04… (added to known_hosts)
  build.tar.zst (48213004 bytes)

# on the RECEIVER
authorized 74318e3b… (added to /home/you/.config/relayium/authorized_fingerprints)
received 1 file(s), 48213004 bytes from 74318e3b…

لا مُرحِّل ولا احتياطي: إن تعذَّر الوصول إلى المُستمِع، تفشل الدفعة — ولا تمر بايتات الملف أبدًا عبر أي طرف آخر.
المحرك نفسه المُستخدَم في الأوضاع الأخرى: يُفحَص كل ملف بـ SHA-256 لكل ملف ويوضع في منطقة مؤقتة قبل تثبيته. ولا يستأنف push، لا هنا ولا عبر SSH — فهو يرفض وجهة موجودة سلفًا. وإذا انقطع التشغيل، أكمِله بدفع المسارات الناقصة أو باستخدام relayium sync الذي يُكمل ملفًا جزئيًا ويحترمه هذا المُستمِع ما لم يكن قد بدأ بـ --no-resume.

اعتمِد المُرسِل عند أول دفعة (على المُستقبِل)

في أول مرة يدفع فيها جهاز جديد إلى مُستمِعك، يُظهِر لك serve (في طرفية) من أين أتى وبصمته ويطلب منك اعتماده — مثل مُطالبة الاتصال الأول في SSH، لكن على جانب المُستقبِل:

# على المُستقبِل، حين يدفع مُرسِل جديد:
Incoming push from 203.0.113.7:54021
  fingerprint: 74318e3b…
Accept and remember this peer? [y/N] y

أجِب بـ y فتُحفَظ تلك البصمة في authorized_fingerprints؛ عندئذٍ تمر كل دفعة لاحقة من الجهاز نفسه بصمت.
البصمة هوية ثابتة للجهاز (تصمد عبر إعادة التشغيل وتغيّر عناوين IP)، فالاعتماد خطوة تُنفَّذ مرةً واحدة لكل مُرسِل.
أما المُرسِل، فيتعلَّم مفتاح المُستمِع عند أول اتصال (الثقة عند أول استخدام) ويُثبِّته في known_hosts.

أتمِتها (أو شغّلها دون طرفية)

بما أن البصمة المعتمَدة تُحفَظ، لا تحتاج الدفعات اللاحقة إلى مُطالبة — لذا يدخل relayium push مباشرةً في سكربت نشر أو CI لتسليم مُشفَّر ومفحوص السلامة من خادم إلى خادم. أما المهمة المُجدوَلة التي تكتب في المجلد نفسه فاستخدم لها relayium sync بدلًا من ذلك: يرفض push وجهة موجودة سلفًا، فالدفع المتكرر إلى مسار ثابت ينجح مرة واحدة ثم يُرفَض بعدها. حين يعمل serve دون طرفية (خدمة systemd، أنبوب) لا يستطيع المُطالبة، فيرفض المُرسِلين المجهولين؛ فوّض لهم مسبقًا بدلًا من ذلك. احصل على البصمة من relayium id لدى المُرسِل، أو انسخها من سطر «rejected unauthorized peer …» في سجل serve، ثم:

# على المُستقبِل: فوِّض مُرسِلًا مسبقًا دون مُطالبة
relayium authorize --config-dir /etc/relayium 74318e3b...

تقيم ملفات الهوية والثقة في ~/.config/relayium/ (تُتجاوَز بـ --config-dir، مثلًا /etc/relayium لخدمة).
authorize خاملة التكرار (idempotent) — تشغيلها مجددًا للبصمة نفسها لا يفعل شيئًا.

شغّل المُستمِع تحت systemd

لصندوق وارد دائم التشغيل، شغّل serve كخدمة systemd. وجِّه --config-dir إلى موقع ثابت مثل /etc/relayium كي تبقى الهوية مستقرة عبر إعادات التشغيل، ودع systemd يُبقيها حيّة:

# /etc/systemd/system/relayium-serve.service
[Unit]
Description=Relayium daemon-direct listener
After=network-online.target

[Service]
ExecStart=/usr/local/bin/relayium serve --dir /srv/inbox --config-dir /etc/relayium
Restart=always
User=relayium

[Install]
WantedBy=multi-user.target

systemctl enable --now relayium-serve لتشغيلها ولرفعها عند الإقلاع.
أبقِ /etc/relayium/id.key قابلًا للقراءة من مستخدم الخدمة فقط — يرفض relayium تحميل مفتاح بأذونات فضفاضة.

حين لا تمرّ الدفعة

إمكانية الوصول والثقة هما أول ما تفحصه: يُظهر ss -tinp على المُرسِل ما إذا كان المُستمِع قد وصلته الحزم أصلًا، ويمنح relayium authorize على المُستقبِل الثقةَ الناقصة لمُرسِل مرفوض. وليستا الطريقتين الوحيدتين لفشل الدفعة — فالمُستقبِل الذي نفدت مساحته، أو مجلد الوارد الذي لا يستطيع مستخدمه الكتابة فيه، أو ملف مَنقول يسقط في فحص السلامة، كلها تُبلِغ عن نفسها — فاقرأ الخطأ الذي أمامك بدل افتراض أنه أحد الأربعة أدناه.

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

تبقى الدفعة واقفة ثم تفشل بخطأ في الاتصال.

# على المُرسِل، أثناء عمل الدفعة — نفّذه مرتين بفارق ثوانٍ قليلة
ss -tinp dst :9031
# ESTAB    يعني أن المُستمِع تم الوصول إليه، ولا يقول شيئًا عن التقدّم
# SYN-SENT لم يردّ أحد على ذلك المنفذ

تعني SYN-SENT أن الحزم لم تصل قط إلى مقبس يستمع. تأكّد على المُستقبِل من أن serve يعمل عبر ss -tlnp | grep 9031، ثم افتح 9031/TCP أمام المُرسِل في جدار حماية المضيف وفي مجموعة الأمان السحابية. لا تثبت ESTAB إلا إمكانية الوصول، فالمقبس المُنشأ قد يبقى خاملًا أو متعطّلًا؛ ولتمييز الحركة من التوقّف نفّذ الفحص مرتين بفارق ثوانٍ قليلة وقارِن عدّاد bytes_acked الذي يطبعه ‎-i‎ لذلك المقبس. لا يوجد هنا مسار عبر مُرحِّل، فالمُستمِع غير القابل للوصول فشل قاطع لا بطء.

يذكر سجل serve عبارة «rejected unauthorized peer …» وتفشل الدفعة.

# على المُرسِل
relayium id
# 74318e3b…

# على المُستقبِل
relayium authorize --config-dir /etc/relayium 74318e3b…

لم تكن لدى serve طرفية يسأل عليها، كوحدة systemd أو أنبوب، فتُرفَض البصمة المجهولة بدل الوثوق بها. اعتمِدها مسبقًا: البصمة في سطر الرفض هي نفسها التي يطبعها relayium id على المُرسِل، وauthorize لا يتغير أثره بتكراره.

«fingerprint mismatch for receiver.example.com:9031».

grep receiver.example.com ~/.config/relayium/known_hosts

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

تموت وحدة systemd عند الإقلاع بخطأ عن أذونات غير آمنة.

systemctl status relayium-serve
# secure: /etc/relayium/id.key has insecure permissions 0644; run: chmod 600 /etc/relayium/id.key
ls -l /etc/relayium/id.key

يرفض relayium تحميل مفتاح خاص يستطيع أحد غير مالكه قراءته، وهي القاعدة نفسها التي يطبّقها ssh. نفّذ chmod 600 على المسار الذي يسمّيه الخطأ، وتأكّد من أن مالكه هو مستخدم الخدمة، ثم أعِد تشغيل الوحدة.

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

بماذا يختلف daemon direct عن push عبر SSH؟

يوجِّه push عبر SSH النقل خلال اتصال SSH لديك ويحتاج إلى حساب SSH على الطرف البعيد. أما daemon direct فلا يحتاج SSH ولا حسابًا — يصادق الخادمان أحدهما الآخر ببصمة الشهادة عبر TLS مُثبَّت، وهو أخف حين يكون الجهازان كلاهما لك.

هل عليّ نسخ البصمات يدويًا هنا وهناك؟

لا. في طرفية، يطالبك serve باعتماد كل مُرسِل جديد عند أول دفعة له — مُظهِرًا عنوانه وبصمته — ويحفظه، فتمر الدفعات اللاحقة بصمت. لا تلجأ إلى relayium id أو relayium authorize إلا في الإعدادات غير التفاعلية مثل خدمة systemd، حيث لا أحد ليُجيب على المُطالبة.

أين تقع ملفات الهوية والثقة؟

في ~/.config/relayium/ افتراضيًا (تُتجاوَز بـ --config-dir). id.key / id.crt هما الهوية الدائمة لهذا المضيف، ويحتفظ known_hosts ببصمات المُستمِعين الذين دفعت إليهم، أما authorized_fingerprints فهو قائمة السماح بالمُرسِلين لدى المُستمِع.

ماذا يحدث إذا تغيّرت بصمة؟

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

هل هناك احتياطي عبر مُرحِّل؟

لا. يفترض daemon direct عنوان مُستمِع يمكن الوصول إليه؛ فإن تعذَّر إنشاء الاتصال، يفشل. لا يُوجَّه أي شيء أبدًا عبر Relayium — وهذا هو مغزى هذا الوضع.

اربط خادمين من خوادمك للنقل المباشر — دون مُرحِّل، دون SSH، دون رمز اقتران.

احصل على CLI