Linux پر Transmission: عمل کے مالک کے مطابق باہر جانے کو لازم کریں

Transmission کی داخلی پورٹ کو بند کرنا VPN پالیسی نہیں ہے۔ ٹورنٹ کلائنٹ ہم منصبوں اور ٹریکرز کی طرف بھیجے جانے والے روابط کھولتا ہے، نام حل کرتا ہے اور دور سے کنٹرول کے لیے سننے والا کھول سکتا ہے، اور ان میں سے ہر ایک ایسے انٹرفیس سے باہر جا سکتا ہے جس کا آپ نے ارادہ نہیں کیا تھا۔ پانچ جانچیں ترتیب سے کریں اور فائر وال قاعدے کو، نہ کہ کلائنٹ کی ترتیبات کو، حد سمجھیں۔ آخری دو جانچیں وہی ہیں جنہیں لوگ چھوڑ دیتے ہیں، اور وہی طے کرتی ہیں کہ ٹنل گرنے پر ضمانت قائم رہتی ہے یا نہیں۔

اس عمل کا نام لیں جو منتقلی کا مالک ہے

ڈیسک ٹاپ ایپلیکیشن اور سسٹم ڈیمون مختلف اکاؤنٹس کے تحت چلتے ہیں، اور مالک کی بنیاد پر قاعدہ پروگرام کے نام کے بجائے اکاؤنٹ کی پیروی کرتا ہے۔ کوئی بھی قاعدہ لکھنے سے پہلے معلوم کریں کہ ان دونوں میں سے کون چل رہا ہے۔ الگ سروس اکاؤنٹ پالیسی کو درست موضوع دیتا ہے، جبکہ ڈیسک ٹاپ صارف اپنی شناخت براؤزرز، ایڈیٹرز اور سیشن کی ہر دوسری چیز کے ساتھ بانٹتا ہے۔ UID کی تصدیق کریں، یہ فرض نہ کریں کہ پیکیج کا اکاؤنٹ نام ہی استعمال ہو رہا ہے۔

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

اگر اکاؤنٹ ابھی موجود نہیں تو اس مقصد کے لیے بنائیں اور اسے چلانے کے لیے کچھ اور نہ دیں۔ اکاؤنٹ اور UID قاعدے کی تشریح میں لکھیں، کیونکہ بغیر موضوع کا قاعدہ ایسا قاعدہ ہے جسے کوئی بھی محفوظ طریقے سے تبدیل نہیں کر سکتا۔

سننے کے میدانوں کو راستے سے الگ کریں

Transmission 4.x ہم منصبوں کے سننے کے پتے rpc-bind-address سے الگ دستاویز کرتا ہے، اور یہ فرق اہم ہے۔ RPC ترتیب صرف دور سے کنٹرول کے سننے والے کو کنٹرول کرتی ہے، اس لیے اسے بدلنا ہم منصب ٹریفک کے لیے راستہ نہیں چنتا۔ دونوں ترتیبات کو ایک پڑھنا اس کی سب سے عام وجہ ہے کہ ظاہری طور پر محتاط کنفیگریشن پھر بھی رس رہی ہوتی ہے۔ یہی دستاویز ایک متبادل صورت بیان کرتی ہے جب ہم منصب کے سننے کا پتہ ناجائز ہو، یعنی دستیاب نہ ہونے والا پتہ دستاویزی متبادل صورت ہے، کوئی یقینی انکار نہیں۔

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

کلائنٹ کے کنٹرولز کو ان کے مقصد کے مطابق استعمال کریں اور ضمانت فائر وال میں رکھیں۔ سننے کی ترتیب اب بھی کارآمد ہو سکتی ہے، لیکن یہ ثابت نہیں کرتی کہ ٹریکرز سے رابطہ، مقامی دریافت یا تفویض شدہ تلاش سب ٹنل سے باہر جاتے ہیں۔ جب یہ دونوں متفق نہ ہوں تو فیصلہ فائر وال کرتا ہے۔

مالک کی مطابقت درست زنجیر میں لکھیں

مالک کی مطابقت کے بارے میں Netfilter کی دستی بتاتی ہے کہ مقامی طور پر بنائے گئے پیکٹ سوکٹ فائل کے مالک صارف یا گروہ سے کیسے منسوب ہوتے ہیں۔ یہ نسبت آگے بھیجی گئی ٹریفک تک نہیں پھیلتی، اور اضافی گروہوں کی مطابقت کے لیے واضح اختیار درکار ہے۔ اسی ایکسٹینشن کی دستی پڑھیں جو آپ واقعی استعمال کر رہے ہیں، نہ کہ پہلی مثال جو ملے۔

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

ترتیب مطابقت جتنی ہی اہم ہے۔ زنجیر کے شروع میں وسیع اجازت آخر میں درست انکار کو کالعدم کر دیتی ہے، اس لیے قاعدہ بڑھا کر امید کرنے کے بجائے پوری زنجیر کا جائزہ لیں۔ اگر میزبان IPv6 چلاتا ہے تو دونوں پتوں کے خاندان شامل کریں، کیونکہ صرف v4 پالیسی ایسا راستہ کھلا چھوڑتی ہے جس کی کوئی نگرانی نہیں کرتا۔ قواعد کو کلائنٹ اور ٹنل کی دوبارہ شروعات میں بھی نصب رکھیں۔

طے کریں کہ tun0 غائب ہونے پر کیا ہوگا

ناکامی کی پالیسی مشق کا اصل مقصد ہے۔ اگر ٹنل غائب ہو جائے اور وہی ہک قواعد ہٹا دے تو کلائنٹ جسمانی انٹرفیس استعمال کرنے میں آزاد ہے جب تک کوئی اور چیز اسے روک نہ دے۔ محفوظ ڈیزائن قواعد رکھتا ہے اور انہیں انکار کرنے دیتا ہے، اور یہی حد کو ٹنل کی صحت سے آزاد بناتا ہے۔ ایسا ہک جو قواعد بھی مٹا دے، ناکامی کی پالیسی کا بالکل الٹ ہے۔

ip link show tun0
iptables -S OUTPUT

اسے جان بوجھ کر جانچیں: ٹنل روکیں، ایسی منتقلی شروع کریں جسے چھوڑنا محفوظ ہو اور دیکھیں کہ کچھ باہر جاتا ہے یا نہیں۔ پھر ٹنل واپس لائیں اور تصدیق کریں کہ مطلوبہ راستہ دوبارہ کام کرتا ہے۔

ان راستوں کو ڈھانپیں جو قاعدہ نہیں دیکھ سکتا

ناموں کا حل ایک الگ حل کرنے والا عمل انجام دے سکتا ہے، اور نام کی جگہ یا مخصوص گیٹ وے ایک اور حد دے سکتے ہیں اگر ان کے اشتراک اور آغاز کے راستے اسی کے لیے بنائے گئے ہوں۔ طے کریں کہ DNS کا مالک کون سا جزو ہے اور کیا وہ اسی خارجی قاعدے کی پیروی کرتا ہے۔ پھر RPC دیکھیں: اگر rpc-whitelist استعمال ہو رہا ہے تو منظور شدہ انتظامی نیٹ ورک معاہدے کا حصہ ہے، اور وسیع RFC1918 رینج نہیں۔

ss -tunp | grep -i transmission

انٹرفیس کاؤنٹرز مشاہدے کی تائید کر سکتے ہیں، لیکن یہ ثابت نہیں کر سکتے کہ کس عمل نے بائٹس پیدا کیے۔ ایسی منتقلی کریں جسے چھوڑنے کی اجازت ہو: پہلے کام کرنے والے راستے پر، پھر آغاز پر ٹنل کے بغیر، پھر رکاوٹ، دوبارہ رابطہ اور نئے بنائے گئے انٹرفیس کے ذریعے۔ نئی کوشش اور پہلے سے کھلا رابطہ دونوں جانچیں، کیونکہ ممکن ہے قاعدہ پرانے سوکٹ پر لاگو نہ ہوا ہو۔ تاریخ، اکاؤنٹ اور نتیجہ جانچ کے ساتھ درج کریں۔

ایسی مثال چسپاں کرنا جو پوری زنجیر صاف کر دے، ایک سوراخ کو کئی سوراخوں سے بدل دیتا ہے، اس لیے قواعد مٹانے کے بجائے شامل کریں۔ جب پانچوں جانچیں گزر جائیں تو ضمانت واضح ہے: کلائنٹ کی ٹریفک ٹنل سے باہر جاتی ہے یا بالکل نہیں جاتی، اور جو قاعدہ اسے لازم کرتا ہے وہ خود ٹنل کی ناکامی سے بھی بچ جاتا ہے۔