Ubuntu پر بوٹ کے وقت OpenVPN: NetworkManager یا systemd؟
لیپ ٹاپ اور بغیر اسکرین والے سرور کو مختلف بوٹ راستے درکار ہوتے ہیں۔ NetworkManager کے ثانوی کنکشن کا openvpn-client@ اور اس کی اسناد کی فائل سے موازنہ کریں۔
زیادہ تر گائیڈیں اس انتخاب کو ظاہری بات کے طور پر پیش کرتی ہیں: یا NetworkManager کو ٹنل اوپر اٹھانے دیں، یا systemd مثال فعال کریں اور ختم۔ دونوں راستے ایک بات میں مختلف ہیں جو بغیر اسکرین والی مشین پر نتیجہ طے کرتی ہے، اور اس کا اس سے کوئی تعلق نہیں کہ کون سا آلہ نیا ہے۔ NetworkManager راز سیشن کے ذریعے کھولتا ہے؛ systemd مثال کے پاس کھولنے کے لیے کوئی سیشن نہیں۔ وہ راستہ چنیں جس کی رازوں کی دیکھ بھال آپ کے سامنے کی مشین سے میل کھاتی ہو۔
باقی سب کچھ، راستوں کی تنصیب سے لے کر دوبارہ جڑنے کے رویے تک، اسی پہلے فیصلے سے نکلتا ہے۔
کی رنگ ہی وہ فرق ہے جس کا کوئی ذکر نہیں کرتا
جب NetworkManager کے پاس VPN پروفائل ہو، تو پاس ورڈ لاگ ان کی رنگ میں رہ سکتا ہے، جو صارف کے سائن ان کرنے پر کھلتا ہے۔ لیپ ٹاپ پر یہ اچھی طرح کام کرتا ہے: شخص موجود ہے، کی رنگ کھلتی ہے، ٹنل اوپر آتی ہے۔ بغیر نگرانی بوٹ ہونے والے سرور پر کچھ کھولنے والا کوئی نہیں، اس لیے پروفائل ایسے راز کا انتظار کرتا ہے جو کبھی نہیں آتا۔ کنکشن ترتیب شدہ دکھائی دیتا ہے اور کبھی فعال نہیں ہوتا۔
systemd مثال ڈسک سے اسناد کی فائل پڑھ کر اس مسئلے سے بچتی ہے، جو فائل کو وہ چیز بنا دیتی ہے جسے آپ محفوظ رکھتے ہیں۔ chmod 400 اور root کی ملکیت کم از کم ہے، اور فائل کو ان بیک اپ اور امیج ٹیمپلیٹس سے باہر رہنا چاہیے جن پر آپ کا کنٹرول نہیں۔
VPN کو کنکشن سے جوڑنا بوٹ کی ضمانت نہیں
nm-connection-editor میں، VPN کی بجائے وائرڈ یا وائرلیس کنکشن منتخب کریں، General ٹیب کھولیں، خودکار طور پر VPN سے جڑنے کا اختیار نشان زد کریں اور پروفائل کو نام دیں۔ پھر جب بنیادی کنکشن جڑی ہوئی حالت میں پہنچتا ہے تو NetworkManager VPN کو ثانوی کنکشن کے طور پر فعال کرتا ہے۔ یہ انحصار ہے، فائر وال قاعدہ نہیں۔ پیکٹ ٹنل کے اوپر آنے سے پہلے کے سیکنڈوں میں اب بھی باہر جا سکتے ہیں، اور محفوظ کیا گیا راز جو کھل نہ سکے مشین کو اس کے بغیر آن لائن چھوڑ دیتا ہے۔
اگر تقاضا یہ ہے کہ ٹنل کے بغیر کچھ باہر نہ جائے، تو یہ کہیں اور کل سوئچ بنائیں، کیونکہ یہ ترتیب ایک بھی فراہم نہیں کرے گی۔ سسپنڈ اور ریزوم بھی آزمائیں، کیونکہ واپسی کے راستے میں ثانوی کنکشن دوبارہ جانچا جاتا ہے۔
systemd مثال کو میل کھاتا فائل نام درکار ہے
پروفائل کو اس کلائنٹ ڈائریکٹری میں رکھیں جس کی پیکیج توقع کرتا ہے، مثلاً /etc/openvpn/client/office.conf، اور اندر سے اسناد کی فائل کا حوالہ auth-user-pass office.cred سے دیں۔ مثال کا نام بغیر لاحقے کے فائل نام ہے، اس لیے openvpn-client@office فائل office.conf پڑھتا ہے۔ اسے sudo systemctl enable --now openvpn-client@office سے فعال کریں اور بلاگ کی مثال پر بھروسا کرنے کی بجائے systemctl cat openvpn-client@office سے مطابقت کی تصدیق کریں۔
پروفائل کے اندر کے راستے پروفائل کی بجائے یونٹ کی ورکنگ ڈائریکٹری کی نسبت حل ہوتے ہیں، اس لیے نسبتی ca یا auth-user-pass سطر بوٹ کے وقت ناکام ہو سکتی ہے جبکہ ہاتھ سے جانچنے پر کام کرتی ہے۔ یونٹ کو جو کچھ ملنا چاہیے اس کے لیے مطلق راستے استعمال کریں۔ پھر حقیقی بوٹ کے بعد journalctl -u openvpn-client@office -b پڑھیں؛ ٹنل کے بغیر فعال بتانے والا یونٹ عام طور پر اس لاگ میں کسی غائب فائل کا نام لیتا ہے۔
پرانی پیکیجیں مختلف ٹیمپلیٹ نام لاتی ہیں، اس لیے systemctl list-unit-files 'openvpn*' طے کرتا ہے کہ اس ہوسٹ پر کون سا موجود ہے۔
دوبارہ جڑنے کا رویہ الگ فیصلہ ہے
ping-restart والا پروفائل ٹنل گرنے کے بعد اسے دوبارہ بناتا ہے، اور ری اسٹارٹ ہدایت والا یونٹ سروس کی سطح پر کچھ ایسا ہی کرتا ہے۔ یہ وہ پالیسیاں ہیں جو آپ چنتے ہیں، نہ کہ وہ ڈیفالٹ جو آپ کو ورثے میں ملتے ہیں۔ اگر کنکشن صرف طلب پر اوپر آنا چاہیے، تو ری اسٹارٹ رویہ جان بوجھ کر ہٹائیں اور وجہ لکھیں۔ اگر یونٹ نیٹ ورک کے قابل استعمال ہونے سے پہلے شروع ہوتا ہے، تو اسے دوبارہ کوشش کی پالیسی درکار ہے، کیونکہ بوٹ کے وقت ایک ناکام کوشش خود بخود نہیں دہرائی جاتی۔
روکنا بھی اتنا ہی لفظی ہے: sudo systemctl disable --now openvpn-client@office چلتی مثال کو روکتا ہے اور بوٹ لنک ہٹاتا ہے۔ صرف غیر فعال کرنا ٹنل کو اگلی ری بوٹ تک چلتا رہنے دیتا ہے، جو ہر اس شخص کو حیران کرتا ہے جو غیر فعال کر کے جانچتا ہے اور انٹرفیس کو اوپر ہی رہتے دیکھتا ہے۔
ری بوٹ کریں، پھر چار چیزیں ترتیب سے جانچیں
سروس کو ری اسٹارٹ کرنا سروس کو جانچتا ہے؛ مشین کو ری بوٹ کرنا بوٹ راستے کو جانچتا ہے۔ ری بوٹ کے بعد تصدیق کریں کہ یونٹ اوپر آیا، پھر کہ دور دراز سب نیٹ کے لیے راستہ موجود ہے، پھر کہ مشین انٹرنیٹ کو کون سا پتہ دکھاتی ہے، اور آخر میں کہ نام ٹنل کے ذریعے حل ہوتے ہیں۔ کچھ غلط ہونے پر وہ چاروں جانچیں اسی ترتیب سے ناکام ہوتی ہیں، جو پہلی ناکامی کو کارآمد بناتی ہے۔
راستے کے بغیر فعال یونٹ کا عام مطلب یہ ہے کہ پروفائل جڑ گیا مگر سرور نے کوئی راستہ نہیں دھکیلا، یا راستہ ایسے انٹرفیس پر نصب ہوا جو بعد میں غائب ہو گیا۔ جس راستے میں ناموں کی تلاش کام نہ کرے وہ ٹنل کی بجائے DNS ترتیب کی طرف اشارہ کرتا ہے۔
پہلے سے طے کریں کہ ٹنل اوپر نہ آ سکے تو کیا ہونا چاہیے۔ عام کنیکٹیویٹی پر واپس آنا ایک پالیسی ہے، اور اسے پہلے شروع ہونے والے کسی بھی منتظم پر چھوڑنے کی بجائے لکھ لینا چاہیے۔