ایک پروفائل، دو مالک: NetworkManager یا systemd

.ovpn فائل کے ساتھ تب تک کچھ نہیں ہوتا جب تک کوئی چیز اس کی مالک نہ ہو۔ Pi ڈیسک ٹاپ پر ممکنہ مالک NetworkManager ہیں، جو درآمد شدہ کنکشن اپنی کلید فائل میں رکھتا ہے، اور ایک الگ سروس یونٹ، جو کسی ڈائریکٹری سے ترتیب پڑھتا ہے۔ یہ مختلف ذخیرہ، مختلف اسناد سنبھالنے اور مختلف فعال کرنے کے قواعد والے دو آپریٹنگ ماڈل ہیں۔ ان میں سے ایک کو جان بوجھ کر چننا ہی پورا کام ہے؛ فائل کو دونوں جگہ نقل کرنا انتخاب کو محض اتفاقی بنا دیتا ہے۔

دونوں ایک ہی مشین پر کام کر سکتے ہیں، لیکن ایک ہی وقت میں ایک ہی ٹنل پر نہیں، اور تنازعہ ترتیب کی خرابی کی طرح نہیں، نیٹ ورک کی خرابی کی طرح لگتا ہے۔

ایک ہی ٹنل کا مالک ہونے کے دو طریقے

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

یہ ایک چیز کے دو رخ نہیں ہیں۔ ڈاؤن لوڈ شدہ فائل میں ترمیم نہ NetworkManager کے محفوظ کردہ کو بدلتی ہے نہ یونٹ کے پڑھے ہوئے کو، اور ان میں سے کوئی بھی وہ ہو سکتا ہے جس نے وہ ٹنل بنایا جو آپ نے ابھی جانچا۔

اُس کنکشن کی پیروی کریں جو ڈیسک ٹاپ واقعی استعمال کرتا ہے

دستاویز شدہ درآمدی عمل، nmcli connection import type openvpn file office.ovpn، پلگ ان کے ذریعے کنکشن بناتا ہے۔ اس کا UUID نوٹ کریں اور آگے وہی شناخت استعمال کریں، کیونکہ نام تبدیل ہوتے ہیں اور دو کنکشن ایک ہی لیبل شیئر کر سکتے ہیں۔ nmcli connection show فہرست دکھاتا ہے کہ کیا موجود ہے، اور کنکشن کی اپنی خصوصیات پڑھنے سے پتہ چلتا ہے کہ وہ کس فائل سے آیا اور کیا رکھتا ہے۔ اگر آپ جس UUID میں ترمیم کر رہے ہیں وہ وہ نہیں جو ڈیسک ٹاپ فعال کرتا ہے، تو آپ کی ترامیم محض سجاوٹ ہیں۔

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

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

یونٹ ٹیمپلیٹ پر بھروسہ کرنے سے پہلے اسے پڑھیں

جہاں پیکج upstream طرز کا کلائنٹ یونٹ فراہم کرتا ہے، وہاں office نامی مثال یونٹ کی ترتیب شدہ ڈائریکٹری میں موجود %i.conf فائل سے مماثل ہے، اور 2.6 ٹیمپلیٹ کے لیے وہ /etc/openvpn/client ہے۔ کسی گائیڈ کی مثال پر بھروسہ کرنے سے پہلے نصب شدہ یونٹ اور کوئی بھی اضافی فائل پڑھیں، کیونکہ تقسیمیں راستے بدل دیتی ہیں۔ ٹرمینل سے ہاتھ سے چلانا فائلوں، رازوں یا اجازتوں کے بارے میں سروس کے نقطہ نظر کا کچھ بھی ثابت نہیں کرتا۔ ڈیسک ٹاپ کا پاس ورڈ ڈائیلاگ بھی اس بات کا ثبوت نہیں کہ غیر تعاملی یونٹ کے پاس وہی پاس ورڈ حاصل کرنے کا منظور شدہ طریقہ ہے۔

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

رسائی کھوئے بغیر نقل ہٹائیں

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

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