VPN کے ذریعے 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