rsync عبر الشبكة الخاصة الافتراضية: منفذ الخدمة 873 مقابل وضع SSH
المنفذ 873 خدمة داخلية ينقلها النفق، وهو ليس بديلاً عنها. ميّز وضع الخدمة من وضع SSH، ثم افتح فقط المسار الذي تستخدمه فعلاً.
السماح بمنفذ TCP 873 على واجهة النفق لا يدفع rsync عبر OpenVPN، ولا يجعل الطرف الآخر يقبل الوحدة. النفق يحمل اتصالاً داخلياً تبقى قواعد بروتوكوله وجهته كما هي تماماً. لذا فالسؤال الأول ليس أي منفذ يُفتح، بل أي نوع من الاتصالات يجريه rsync. كل ما يلي يفترض أن النفق قائم بالفعل وأن الخدمة الداخلية وحدها لا تزال موضع شك.
حدّد نوع الاتصال الذي يجريه rsync فعلاً
وسيط الجهة البعيدة في الأمر يجيب عادةً عن ذلك السؤال قبل أي تغيير في جدار الحماية. النقطتان المزدوجتان أو مخطط URL يختاران الخدمة، بينما النقطتان المفردتان بعد اسم المضيف تختاران صدفة بعيدة. اقرأ الوسيط الذي تشغّله فعلاً لا الذي في مثال الوثائق.
يمكن لخيار صدفة بعيدة صريح أن يغيّر الجواب مرة أخرى، لأنه يخبر rsync أي برنامج يشغّل للنقل. اقرأ سطر الأمر كاملاً، بما في ذلك سكربتات التغليف الموروثة، لا جزء المضيف وحده.
| Remote argument | What it opens |
|---|---|
rsync://vault.corp.internal/archive/ | rsync daemon, normally TCP 873 |
vault.corp.internal::archive/ | rsync daemon, normally TCP 873 |
[email protected]:/srv/archive/ | Remote shell, normally SSH on its configured port |
وضع الخدمة: عنوان الربط والوحدة والمنفذ
في صيغة الخدمة يشير مقطع المسار إلى وحدة مُهيّأة، لا إلى دليل على القرص. لا تُفحص كلمة مرور الوحدة إلا بعد قبول الاتصال، وقد تكون الوحدة أيضاً للقراءة فقط أو مخفية عن الإدراج. هذا الترتيب مهم عند قراءة خطأ، لأن الاتصال المرفوض والوحدة المرفوضة فشلان في مرحلتين مختلفتين. ولا تخبرك أي من الرسالتين بشيء عن النفق نفسه.
يمكن تثبيت خدمة مستقلة على عنوان النفق في ملف تهيئتها، ما يبقيها بعيداً عن الواجهة العامة دون أي قاعدة جدار حماية. يجب أن تكون القيمة موجودة حين تربط الخدمة، وقد يتجاهلها مستمع مُشغّل بالمقبس أو يديره inetd تماماً.
address = 10.44.0.1
port = 873
[archive]
path = /srv/archive
read only = yesاختبر بعد ذلك العنوان الخاص لا الاسم العام. اسم مضيف عام يُحلّ إلى عنوان WAN ويسلك مساراً مختلفاً، حتى حين تستجيب آلة واحدة على الاثنين.
rsync --list-only rsync://10.44.0.1/archive/وضع الصدفة البعيدة: SSH يحمل النقل
بنقطتين مفردتين يبدأ rsync برنامج صدفة بعيدة ويتكلم بروتوكوله عبر تلك القناة، لذا فالخدمة الوحيدة التي يمكن الوصول إليها هي SSH على أي منفذ يستمع عليه الخادم. خدمة rsync لا تعمل أبداً، والمنفذ 873 غير ذي صلة، وقرار الوصول يصبح قرار حساب SSH. والمسار البعيد عندئذ مسار نظام ملفات حقيقي تفسّره الصدفة على الطرف الآخر. لهذا لا يفعل تغيير في جدار الحماية يستهدف 873 شيئاً على الإطلاق في هذا الوضع.
يحتاج هذا التصميم إلى حساب مُصرّح به والتحقق من مفتاح المضيف، وهو يورث سياسة المصادقة الخاصة بـ SSH. وكثيراً ما يكون الخيار الأفضل حين يجب أن يعبر النقل شبكة غير موثوقة، لأن التشفير ينتمي إلى بروتوكول بُني له. أما خدمة تطلب كلمة مرور فليست الشيء نفسه.
افتح فقط المسار الذي اخترته
متى استقر الوضع، اسمح بالخدمة الداخلية الواحدة على الواجهة الواحدة التي تحمل النفق. ضيّق القاعدة بحسب الواجهة ومجموعة المصادر وعنوان الوجهة كي لا يوسّعها لاحقاً تغيير في المنع الافتراضي بصمت. راجع ترتيب القواعد بعد ذلك، لأن قاعدة متساهلة في وقت أبكر من السلسلة تجعل الضيقة زخرفة.
إن كانت الخدمة تعمل على آلة خلف بوابة VPN لا على البوابة نفسها، فالبوابة تحتاج مسار توجيه أيضاً والهدف يحتاج إذنه الخاص ومساره العائد. وفتح المنفذ على البوابة وحدها ينتج اتصالاً يُقبل ثم لا يذهب إلى أي مكان.
تحقّق من العميل بالوضع والوجهة نفسيهما اللذين تنوي استخدامهما في الإنتاج. إدراج ناجح يثبت المستمع والمسار والقاعدة معاً؛ والمهلة تشير إلى المسار، والرفض يشير إلى المستمع.
ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873