UID قاعدے کے ساتھ ایک Linux اکاؤنٹ کو OpenVPN سے روٹ کرنا

اکاؤنٹ کی بنیاد پر روٹنگ اُس وقت موزوں ہوتی ہے جب ایک Linux صارف کی ملکیت میں موجود ہر IPv4 ساکٹ کو موجودہ ٹنل سے باہر جانا چاہیے، اور یہ اُس وقت موزوں نہیں ہوتی جب آپ کو پروگرام کی سطح پر الگ تھلگ کرنا درکار ہو۔ یہ UID کے مطابق چنتا ہے، اس لیے اُس اکاؤنٹ کے تحت چلنے والی ہر چیز دائرے میں آتی ہے، وہ بیچ کام بھی جو آپ بھول گئے۔ ایک بھی ip rule کو چھونے سے پہلے یہ سوال طے کر لیں۔

نیچے دی گئی مثال UID 1500 پر ایک مخصوص براؤزر اکاؤنٹ، 10.80.0.11 مقامی پتہ رکھنے والا ٹنل آلہ tun-office، اور ایک ایسا VPN فرض کرتی ہے جو زیرِ بحث منزلوں کی اجازت دیتا ہے۔ ڈیمن خود اُس UID سے باہر چلتا ہے۔

وہ تین شرطیں جو میکانزم چنتی ہیں

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

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

جدول، قاعدہ اور محافظ

موجودہ قواعد جانچنے اور غیر استعمال شدہ جدول و ترجیحی نمبر چننے کے بعد ترتیب مختصر ہے: ٹنل کا ماخذ پتہ رکھنے والے مخصوص جدول میں طے شدہ راستہ، اکاؤنٹ کی تلاشوں کو اُس جدول میں بھیجنے والا قاعدہ، اور متبادل راستے کو روکنے والا آخری قاعدہ۔ لکھے جانے پر یہ idempotent راستہ تبدیلی ہے، ip -4 route replace default dev tun-office src 10.80.0.11 table 51820، جس کے بعد ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820 آتا ہے۔

محافظ ip -4 rule add priority 12101 uidrange 1500-1500 unreachable ہے، اور یہ اپنی لمبائی کے اشارے سے زیادہ اہم ہے۔ اُس کے بغیر جدول 51820 میں غائب راستہ عام اوپر کے لنک میں گر جاتا ہے اور اکاؤنٹ خاموشی سے وہ ٹریفک بہا دیتا ہے جو پالیسی کو پکڑنا تھا۔ اُس کے ساتھ وہی ناکامی وقت کی حد بن جاتی ہے، یعنی متبادل نہیں بلکہ روک۔

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

UID روٹنگ کیا چھوڑ دیتی ہے: DNS

حل کنندہ ڈیمن اپنے اوپر کے ساکٹ اپنے UID کے تحت کھولتا ہے، اس لیے 1500 چننے سے وہ سوالات جدول 51820 میں منتقل نہیں ہوتے۔ DNS کا اتحاد الگ فیصلہ ہے: اکاؤنٹ کو ٹنل سے قابلِ رسائی حل کنندہ کی طرف اشارہ کریں، یا مان لیں کہ ناموں کا حل میزبان کے راستے پر چلتا ہے جبکہ ٹریفک نہیں۔

مقامی stub کی طرف loopback سوال اس بات کا ثبوت نہیں کہ اوپر والے سوال نے براؤزر کا راستہ استعمال کیا، اور نہ ہی کیش سے کامیاب صفحہ لوڈ۔

IPv6 کو ڈیزائن میں اپنا جملہ درکار ہے

اوپر کے قواعد صرف IPv4 کو ڈھانپتے ہیں۔ اگر ضرورت اِس اکاؤنٹ سے براہِ راست IPv6 کے بغیر IPv4 ٹنل ہے، تو جائزہ شدہ آخری قاعدہ شامل کریں مثلاً ip -6 rule add priority 12101 uidrange 1500-1500 unreachable، پھر پہلے کے IPv6 قواعد اور وہ loopback استثنائیں جانچیں جو آپ رکھنا چاہتے ہیں۔

براہِ راست IPv6 کو روکنا دوہری تہہ ٹنلنگ نہیں؛ یہ ایک حد ہے۔ اِسے ٹنلنگ کہنا اگلے پڑھنے والے کو الجھا دے گا، اور یہ الجھن خراب IPv6 سائٹ کے بارے میں ہیلپ ڈیسک ٹکٹ کی صورت میں سامنے آئے گی۔

اصلی اکاؤنٹ سے تصدیق کریں، پھر زندگی کے چکر کی ذمہ داری لیں

تلاشوں کا موازنہ کریں: عام UID کے ساتھ اُسی منزل کے لیے ip -4 route get 198.51.100.25 uid 1500۔ پھر مخصوص اکاؤنٹ کے تحت اجازت یافتہ درخواست کریں اور وہ ماخذ پتہ جانچیں جو دور کا سرا دیکھتا ہے۔ ترجیحی ماخذ پتہ source NAT نہیں، اور یہ کسی اور چیز کو بائنڈ کرنے والی ایپلیکیشن پر غالب نہیں آئے گا۔ اگر دونوں تلاشیں ایک ہی راستہ دیں، تو قاعدہ وہ نہیں کر رہا جو آپ سمجھتے ہیں۔

جدول، قواعد اور ٹنل راستے کی عمر ایک ہی مالک کے تحت رکھیں، دوبارہ جڑنے اور ٹنل کھو جانے کا تجربہ کریں، اور پالیسی ہٹاتے وقت صرف اُس کے درست اندراجات ہٹائیں۔ اگر الگ انٹرفیس اور الگ حالت واقعی درکار ہوں تو namespace اب بھی دستیاب ہے۔