آپ کا VPN صرف لاگ ان کے بعد کام کرتا ہے، کی رنگ کی وجہ سے

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

لاگ ان اسے کیوں چلاتا ہے

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

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

طے کریں کون مالک سرنگ شروع کرتا ہے

دو معاون نمونے ہیں، اور انہیں ملانا اس کے ناکام ہونے کا دوسرا طریقہ ہے۔ NetworkManager نظامی سطح کا کنکشن فعال کر سکتا ہے، جو اس وقت موزوں ہے جب مشین پہلے ہی وہاں اپنی نیٹ ورکنگ مرکوز کر چکی ہو۔ متبادل طور پر، ایک مخصوص systemd یونٹ VPN کو براہ راست چلاتا ہے اور خود انٹرفیس کا مالک ہے۔

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

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

راز وہاں رکھیں جہاں سروس اسے پڑھ سکے

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

لحاظ والا شارٹ کٹ یہ ہے کہ فائل کو اس وقت تک عالمی قابل مطالعہ بنا دیا جائے جب تک اجازت کی خرابی غائب نہ ہو جائے۔ یہ اسٹارٹ اپ ناکامی کو طویل المدتی اسناد کی لیک سے بدل دیتا ہے، اور یہ اسی قسم کی تبدیلی ہے جس کا کوئی دوبارہ جائزہ نہیں لیتا۔ وہ طریقہ کار استعمال کریں جس پر تعیناتی پہلے ہی بھروسہ کرتی ہے: محدود اسناد فائل، فائل اجازتوں سے محفوظ غیر خفیہ شدہ کلید، یا اپنے رازخانے والا نظامی سطح کا کنکشن۔

اس واقعہ کی جانچ کریں جو واقعی پیش آتا ہے

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

صرف انٹرفیس نہیں، راستے اور DNS بھی جانچیں

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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