آپ کے VPN عمل کو کون سی Linux صلاحیتیں درکار ہیں؟
انٹرفیس سیٹ اپ، راستے، ڈیوائس تک رسائی اور عام ساکٹ الگ الگ اختیارات ہیں۔ CAP_NET_ADMIN دینے سے پہلے ناکام ہونے والے عمل کا نام بتائیں۔
VPN ڈیمون کو مراعات یافتہ نیٹ ورک کارروائیوں کی ضرورت ہوتی ہے، حالانکہ عام ایپلیکیشنز بغیر کسی مراعات کے باہر جانے والے ساکٹ کھولتی ہیں۔ اسی خلا سے زیادہ تر صلاحیت کی غلطیاں شروع ہوتی ہیں: کوئی اجازت کی غلطی دیکھتا ہے، پورا سیٹ دے دیتا ہے، اور سروس ایسی وجوہات سے چلتی ہے جو بعد میں کوئی بیان نہیں کر سکتا۔ نیچے دیا گیا سفر ناکام ہونے والے عمل سے شروع ہوتا ہے، اسے ایک اختیار سے جوڑتا ہے، اور پھر وہ سیاق دیکھتا ہے جس میں عمل واقعی چل رہا ہوتا ہے۔ لامحدود root کے طور پر چلانا کچھ تعیناتیوں کے لیے درست جواب ہے، لیکن یہ فیصلہ ہونا چاہیے نہ کہ طے شدہ قدر۔
ناکام ہونے والے عمل سے شروع کریں
ٹیوٹوریل پڑھنے سے پہلے غلطی پڑھیں۔ انٹرفیس تبدیلی پر «عمل کی اجازت نہیں»، ڈیوائس نوڈ کھولنے سے انکار اور کم پورٹ پر bind کی ناکامی — یہ تین مختلف مسائل ہیں، تین مختلف اجازتوں کے ساتھ۔ اگر عمل شروع ہو کر صرف پہلی راستہ تبدیلی پر ناکام ہو، تو یہ بھی بتاتا ہے کہ انٹرفیس بنانا پہلے ہی کامیاب ہو چکا ہے، جو جواب کو کافی محدود کر دیتا ہے۔
سروس بند رکھ کر ناکامی دوبارہ پیدا کریں، پھر اگر عمل درآمد اجازت دے تو اسے اسی صارف کے تحت سامنے کے منظر میں شروع کریں۔ جو غلطی آپ دیکھ سکتے ہیں وہ اس لاگ لائن سے بہتر ہے جس کا اندازہ لگانا پڑے، اور یہ صلاحیت کے مسئلے اور SELinux یا AppArmor کے انکار کے درمیان فرق واضح کرتی ہے۔
ہر عمل کو ایک اختیار سے جوڑیں
جدول ایک ابتدائی نقشہ ہے، عمل درآمد کی دستاویز کا متبادل نہیں:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
اس جدول کی دونوں قطاریں وہی ہیں جنہیں لوگ آپس میں ملا دیتے ہیں۔ /dev/net/tun کھولنا فائل اجازت کا سوال ہے؛ جو آپ نے کھولا اسے ترتیب دینے کے لیے کرنل سے کہنا صلاحیت کا سوال ہے۔ CAP_NET_ADMIN دینے سے وہ ڈیوائس نوڈ درست نہیں ہوتا جو آپ کا سروس صارف پڑھ نہیں سکتا، اور نوڈ درست کرنے سے آپ کو راستے کا اختیار نہیں ملتا۔ ان میں سے کوئی بھی بدلنے سے پہلے دونوں جانچیں۔
کرنل کا WireGuard اور صارف فضا کے ٹنل پروگرام بھی یکساں تقاضے نہیں رکھتے۔ کرنل ماڈیول کا راستہ netlink کے ذریعے موجودہ انٹرفیس ترتیب دیتا ہے، جبکہ صارف فضا میں عمل درآمد کو ڈیوائس بھی درکار ہو سکتی ہے اور بعض ترسیل کے لیے خام ساکٹ بھی۔
سیاق پڑھیں: سروس، کنٹینر یا شیل
میزبان کے نیٹ ورک نام فضا میں ایک صلاحیت دانستہ طور پر الگ تھلگ اسٹیک میں اسی عمل سے کہیں زیادہ اثر ڈال سکتی ہے۔ کنٹینر رن ٹائم عام طور پر کم کیے گئے حد سیٹ کے ساتھ شروع ہوتا ہے؛ میزبان کا نیٹ ورک بانٹنے والے کنٹینر میں NET_ADMIN شامل کرنا اپنی نیٹ ورک نام فضا اور میزبان ماؤنٹس کے بغیر والے کنٹینر میں شامل کرنے سے کہیں بڑی اجازت ہے۔
systemd یونٹس کے لیے وہ پڑھیں جو واقعی لاگو ہوتا ہے نہ کہ وہ جو یونٹ فائل کہتی معلوم ہوتی ہے: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities مؤثر اقدار بتاتا ہے، جو آپ کے بھولے ہوئے drop-in نے مقرر کی ہو سکتی ہیں۔ مؤثر قدر مانگیں، کبھی بھی مطلوبہ قدر نہیں۔ Ambient صلاحیتیں اہم ہیں کیونکہ غیر root سروس ان کے بغیر exec میں صلاحیتیں کھو دیتی ہے۔
پیکیج یا امیج کے معاون سیٹ اپ کو بنیاد بنائیں۔ خام ساکٹ کی اجازتیں یا مراعات یافتہ موڈ شامل نہ کریں صرف اس لیے کہ کسی دوسرے ٹیوٹوریل نے انہیں کسی دوسرے آلے کے لیے درج کیا ہے؛ یہ استدلال کچھ منتقل نہیں کرتا اور آپ کی دی ہوئی تنہائی چھین لیتا ہے۔ شک ہو تو کچھ نہ دیں اور اپنے مطلوبہ درست عمل کے لیے عمل درآمد کے نوٹس پڑھیں۔
مراعات کم ہونے کے بعد کیا ہوتا ہے دیکھیں
بہت سے ڈیمون مراعات کے ساتھ شروع ہوتے ہیں، انٹرفیس ترتیب دیتے ہیں، پھر غیر مراعات یافتہ صارف پر منتقل ہو کر ٹنل رکھتے ہیں۔ اس لمحے سے عمل راستہ شامل نہیں کر سکتا، فائر وال قاعدہ دوبارہ نہیں لکھ سکتا یا نیا مراعات یافتہ ڈیوائس نہیں کھول سکتا، جو تب تک درست ہے جب تک دوبارہ رابطہ کو بالکل یہی درکار نہ ہو۔ بعد میں فائل پڑھنا اور ہک چلانا اسی وجہ سے ناکام ہو سکتا ہے۔
پہلا سیکنڈ نہیں، پورا زندگی کا دورانیہ جانچیں: آغاز، تجدید یا دوبارہ رابطہ، اور بند کرتے وقت صفائی۔ انٹرفیس کا پہلی بار کامیابی سے بننا یہ ثابت نہیں کرتا کہ بعد کی ہر مراعات یافتہ کارروائی کام کرتی رہے گی، اور ناکامی عام طور پر پیداوار میں گھنٹوں بعد ظاہر ہوتی ہے۔
صارف کی تبدیلی کے دوران ٹنل کھلا رکھنے والے عمل درآمد عام طور پر اسے ٹنل اور چابیاں محفوظ رکھنے کے اختیارات کے ساتھ جوڑتے ہیں۔ systemd کی جانب مساوی سوال یہ ہے کہ کیا یونٹ کا صلاحیت سیٹ آپ کے ترتیب دیے گئے صارف کی تبدیلی سے بچ جاتا ہے۔
دی گئی اجازت اور اس کی وجہ درج کریں
درست اجازت، وہ عمل جسے یہ ممکن بناتی ہے اور وہ غلطی جسے اس نے درست کیا، لکھیں۔ تعیناتی نوٹس میں ایک سطر — «یونٹ کی نیٹ ورک نام فضا میں CAP_NET_ADMIN، دوبارہ رابطے کے بعد راستہ تبدیلیوں کے لیے درکار» — اگلے شخص کو اجازت دوبارہ بڑھانے سے روکنے کے لیے کافی ہے۔
پھر ہر اپ گریڈ کے بعد مؤثر سیٹ دوبارہ پڑھیں۔ وینڈر خصوصیات شامل کرتے ہیں، امیج طے شدہ اقدار بدلتی ہیں، اور گزشتہ سال غیر ضروری صلاحیت کسی کو معلوم ہوئے بغیر بوجھ اٹھانے والی بن سکتی ہے۔