مراعات کم کرنے کے بعد: کون سی OpenVPN فائلیں اب بھی کام کرتی ہیں؟
کم کرنے سے پہلے کھولے گئے ڈسکرپٹر کام کرتے رہتے ہیں؛ بعد میں دوبارہ کھلنے والے راستے نہیں۔ فیصلہ کریں کہ آپ کے سیٹ اپ کو تین رن ٹائم فائلوں میں سے کون سی دوبارہ کھولنی ہے۔
طویل اپ ٹائم صرف یہ ثابت کرتا ہے کہ اس لمحے ڈیمون کے پاس جو مراعات تھیں ان کے ساتھ آغاز کامیاب ہوا۔ یہاں اہم ناکامیاں بعد میں آتی ہیں: نیا کلائنٹ جڑتا ہے، منسوخی کی فہرست بدلی جاتی ہے، معاون اسکرپٹ کو فائل لکھنی ہوتی ہے۔ ان میں سے ہر ایک بغیر مراعات والے اکاؤنٹ کی نئی کھولائی ہے، جس کا اپنا اجازت کا سوال اور اپنا غلطی کا پیغام ہے۔ تین فیصلے کام کرتی رہنے والی ترتیب کو اگلی واردات میں ناکام ہونے والی سے الگ کرتے ہیں۔
جو جلدی لوڈ ہوا اسے بعد میں کھلنے والے سے الگ کریں
ڈسکرپٹر کھلی فائل تفصیل پر ایک ہینڈل ہے، اور رسائی کا انداز اس تفصیل کے بننے کے وقت ہی طے ہو گیا تھا۔ بعد میں عمل کا صارف بدلنے سے ہینڈل بند نہیں ہوتا، اسی لیے root کے طور پر پڑھی گئی کلید کی فائل کم کرنے کے بعد بھی کام کرتی ہے۔ انداز بھی نہیں بدلتا: پڑھنے کے لیے کھلا ہینڈل لکھنے کے قابل نہیں ہوتا، اور لکھنے کے قابل ہینڈل صرف اس لیے واپس نہیں لیا جاتا کہ اکاؤنٹ نے راستے پر اپنے حقوق کھو دیے۔ یہ دو حقائق ان رپورٹوں میں حیران کن رویے کا زیادہ تر حصہ بیان کرتے ہیں۔
دوسرا نصف حافظہ ہے۔ ڈیمون سرٹیفکیٹ کا تجزیہ کر کے تجزیہ شدہ مواد رکھ سکتا ہے اور فائل بند کر سکتا ہے؛ استعمال میں رہنے والی چیز ڈیٹا ہے، کھلی فائل نہیں۔ اس لیے جاری ٹریفک نہ تو یہ ثابت کرتی ہے کہ ڈسکرپٹر کھلا ہے اور نہ یہ کہ راستے کا نام پہنچ میں ہے۔ یہ صرف یہ ثابت کرتی ہے کہ موجودہ سیشن کے لیے درکار مواد پہلے حاصل کیا گیا تھا۔
بعد میں کھولنا ایک اور معاملہ ہے۔ یہ موجودہ اسناد، موجودہ سلامتی سیاق و سباق اور موجودہ ماونٹ منظر کے تحت چلتا ہے، اس لیے آغاز میں پڑھنے کے قابل راستہ اگلے کنکشن پر مسترد ہو سکتا ہے۔ گردش ایک جال شامل کرتی ہے: اسی راستے کے نام پر نئی فائل لکھنا موجودہ ڈسکرپٹر کو پرانی شے سے جڑا چھوڑ دیتا ہے، اس لیے دوبارہ لوڈ کامیاب دکھ سکتا ہے جبکہ ڈیمون اب بھی پچھلا مواد استعمال کر رہا ہوتا ہے۔ گردش کے مؤثر ہونے پر یقین سے پہلے عمل کے پاس موجود inode کا ڈسک والے سے موازنہ کریں۔
تین رن ٹائم ریڈنگز اور ہر ایک کا وقت نامزد کریں
تین وسائل عام طور پر آغاز کے بہت بعد کھلتے ہیں، اور وہ مختلف لمحوں میں ناکام ہوتے ہیں۔ کسی مخصوص کلائنٹ کی کنفیگریشن فائل اس وقت پڑھی جاتی ہے جب وہ کلائنٹ جڑتا ہے، اس لیے باقی چلتے رہتے ہیں جبکہ ایک صارف کے لیے وہ ٹوٹ سکتی ہے۔ منسوخی کا ڈیٹا ساتھی کی توثیق کے دوران اور فائل بدلنے پر دوبارہ دیکھا جاتا ہے۔ عارضی ڈائریکٹری کو صرف اس وقت چھوا جاتا ہے جب اسکرپٹ یا پلگ ان کچھ لکھے۔
تینوں میں سے کوئی آغاز کے راستے کا نہیں ہے، اسی لیے ہفتوں صحت مند رہنے والا سرور اگلے کنکشن پر ناکام ہو سکتا ہے۔ یہ زمرہ اصلاح کے مالک کا نام بھی لیتا ہے: پہلے دو ڈیمون اکاؤنٹ کے تحت کنفیگریشن پر پڑھنے کی اجازتیں ہیں، اور تیسرا تنگ مقصد والی لکھنے کے قابل جگہ ہے۔
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key زیادہ تر لوگوں کے اندازے سے زیادہ تنگ سوال کا جواب دیتا ہے۔ یہ دستاویزی SIGUSR1 اور ping-restart ری سیٹ کے دوران کلید کی فائل کھلی رکھتا ہے، اور CCD فائلوں، منسوخی کے ڈیٹا، معاون ایگزیکیوٹیبل یا عمل کی مکمل دوبارہ شروعات کے لیے کچھ نہیں کرتا۔ وہ اب بھی اپنے کھولنے کے راستوں پر چلتے ہیں، اس وقت چلنے والے کسی بھی اکاؤنٹ کے تحت۔
اکاؤنٹ اور اس کا حقیقی منظر نامہ یقینی بنائیں
unit فائل پر بھروسا کرنے کے بجائے چل رہے ڈیمون سے پوچھیں کہ وہ کون سا اکاؤنٹ استعمال کر رہا ہے، پھر جواب کا unit کے مقرر کردہ سے موازنہ کریں۔ عدم مطابقت پہلی حل طلب چیز ہے، کیونکہ ہر بعد کی اجازت جانچ اسی کی حیثیت سے چلتی ہے جو عمل واقعی ہے۔ پھر راستہ ایک ایک جزو کے طور پر چلیں؛ گزر کا اندازہ ہر سطح پر ہوتا ہے، اس لیے ناقابل گزر ڈائریکٹری میں پڑھنے کے قابل فائل بھی ناقابل مطالعہ رہتی ہے۔ حتمی فائل موڈ پہلا نہیں، آخری سوال ہے۔
نام کی جگہیں اور سروس سینڈ باکس ایسی حدیں شامل کرتے ہیں جو ملکیت اور موڈ بٹس بیان نہیں کرتے۔ آپ کے شیل میں نظر آنے والا راستہ chroot، ماونٹ نام کی جگہ یا گھریلو ڈائریکٹریاں چھپانے والے unit کے اندر موجود نہ ہو یا صرف پڑھنے کے قابل ہو۔ سلامتی ماڈیول ایک اور تہہ شامل کرتے ہیں، اس لیے پڑھنے کے قابل دکھنے والی فائل کھلتے وقت پھر بھی مسترد ہو سکتی ہے۔
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceمنتظم کے شیل میں کامیاب قرأت ان مشترکہ شرائط میں سے ایک بھی جانچتی نہیں۔ جانچ کو ڈیمون اکاؤنٹ کے طور پر، اسی نام کی جگہ اور سینڈ باکس کے ساتھ چلائیں، یا تسلیم کریں کہ نتیجہ سرور نہیں بلکہ آپ کے شیل کی وضاحت کرتا ہے۔ تیسرا حکم اس امتحان کا سستا نسخہ ہے: یہ ہر جزو کا موڈ چھاپتا ہے اور پہلے اسی جزو پر ناکام ہوتا ہے جسے ڈیمون اکاؤنٹ عبور نہیں کر سکتا۔
رن ٹائم لکھائی کو اپنی ڈائریکٹری دیں
قرأت فہرست کا صرف آدھا حصہ ہے۔ معاون اسکرپٹ کو اسٹیٹس فائل بنانی ہو سکتی ہے، پلگ ان کو اپنی کنفیگریشن کے پاس حالت لکھنی ہو سکتی ہے، اور وہ تحریریں کنفیگریشن کے درخت کو لکھنے کے قابل بنانے سے ڈھکی نہیں جاتیں۔ مخصوص ڈائریکٹری کو اس کے فعل کے لیے درکار تحریر کی اجازت دیں، ایسے مالک اور موڈ کے ساتھ جو آپ بیان کر سکیں۔ صرف پڑھی جانے والی ہر چیز کے لیے صرف پڑھنے کی رسائی کو ترجیح دیں۔
نجی کلید کی اجازتیں پالیسی فائلوں سے الگ رکھیں۔ ری سیٹ کے بعد دوبارہ پڑھی جانے والی کلید کی ضرورت ہر کنکشن پر پڑھی جانے والی کلائنٹ فائل سے مختلف ہے، اور دونوں کے لیے ایک نرم موڈ مسئلے کی طلب سے زیادہ رسائی دیتا ہے۔ تنگ ملکیت والا مخصوص ڈیمون اکاؤنٹ وسیع گروپ سے آسان جانچا جاتا ہے۔ جب کلید کو ری سیٹ برداشت کرنے ہوں، persist-key ڈائریکٹری وسیع کرنے کے بجائے دوبارہ قرأت ہٹا دیتا ہے۔
اسی واقعے سے فیصلہ کریں جسے آپ دہرا سکتے ہیں
زندہ ٹنل کوڈ میں صرف ایک راستہ ثابت کرتی ہے۔ جس واقعے کو فائل درکار ہے وہی واحد امتحان ہے جو آپ کے لیے اہم کھولائی کو ڈھکتا ہے، چاہے وہ نیا کلائنٹ کنکشن ہو، بدلی ہوئی منسوخی فائل ہو، اجازت شدہ نرم ری سیٹ ہو یا منصوبہ بند دوبارہ شروعات۔ واقعہ منتخب کریں، چلائیں، اور آخری نہیں پہلی غلطی رکھیں۔
نرم ری سیٹ کے لیے ایک سگنل اور unit کا لاگ دکھاتے ہیں کہ کلید دوبارہ پڑھی گئی یا نہیں۔ سگنل بھیجیں، پھر unit کی لکھی آخری سطریں پڑھیں:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerیہ نتیجہ نہ نکالیں کہ صرف مراعات کم ہونے سے سمجھوتہ شدہ ڈیمون اب فائلیں تبدیل نہیں کر سکتا۔ وہ اب بھی کیا کر سکتا ہے یہ بقایا اسناد، اس کی صلاحیتوں، جن ڈائریکٹریوں میں لکھ سکتا ہے اور اب بھی رکھے ہوئے کسی بھی لکھنے کے قابل ڈسکرپٹر پر منحصر ہے۔ مراعات کم کرنا اختیار کو تنگ کرتا ہے، اور رن ٹائم کھولائیوں کی فہرست دکھاتی ہے کہ کتنا۔ اس حد کو کنفیگریشن کے پاس لکھیں تاکہ اگلے شخص کو اسے دوبارہ دریافت نہ کرنا پڑے۔