VPN یونٹ نیٹ ورک سے پہلے کیوں شروع ہو کر پھر مر جاتا ہے

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

ہدف ملاقات کا مقام ہے، منتظم نہیں

network-online.target کو معلوم نہیں کہ نیٹ ورک کیا ہے۔ یہ ایک ہم آہنگی کا نقطہ ہے جو اس خدمت کو جمع کرتا ہے جسے لنک قابل استعمال ہونے تک آغاز میں تاخیر کرنی چاہیے، اور تعریف کو اسی نیٹ ورک مینیجر کے سپرد کرتا ہے جو مشین کا مالک ہے۔ زیادہ تر ڈیسک ٹاپ اور سرورز پر اس کا مطلب NetworkManager یا systemd-networkd کی فراہم کردہ انتظار کی خدمت ہے۔ اگر کوئی بھی فعال نہ کریں تو ہدف کے پاس انتظار کے لیے کچھ نہیں رہتا، اس لیے جس لمحے کوئی چیز اسے اندر کھینچتی ہے وہ اسی لمحے مکمل ہو جاتا ہے، اور یہ DHCP کے جواب سے بہت پہلے ہو سکتا ہے۔ آپ کے یونٹ کی ترتیب کی سطر ایماندار تھی اور پھر بھی بیکار۔

اس لیے پہلا سوال یہ نہیں کہ آپ کا یونٹ کیا اعلان کرتا ہے۔ سوال یہ ہے کہ کیا اس مشین پر واقعی کوئی چیز انتظار کر رہی ہے۔

یونٹ فائل کے بجائے آخری بوٹ پڑھیں

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

انحصار کا منظر اس کی تصدیق کرتا ہے۔ اگر سرنگ یونٹ کے لیے اہم زنجیر میں انتظار کی خدمت نہیں ہے تو اس راستے پر کسی چیز نے آغاز میں تاخیر نہیں کی، اور ہدف نے وہ کام نہیں کیا جو آپ نے فرض کیا۔ دو منظر، ایک نتیجہ۔

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

انتظار شامل کریں، پھر دوبارہ کوشش

پیکیج کیے گئے یونٹ میں ترمیم کے بجائے drop-in استعمال کریں، تاکہ پیکیج اپ ڈیٹ تبدیلی کو خاموشی سے نہ پھینکے۔ دو ہدایات اہم ہیں: یونٹ کو ہدف کے بعد ترتیب دیا جانا چاہیے، اور اسے ہدف کو اسی لین دین میں کھینچنا چاہیے۔ صرف ترتیب ہدف کو نہیں بلاتی؛ خواہش یہ کرتی ہے۔

OpenVPN کلائنٹ کا پیکیج کیا گیا یونٹ پہلے ہی دونوں رکھتا ہے۔ ہاتھ سے لکھے گئے یونٹ عام طور پر ایک یا کوئی نہیں رکھتے، جسے کچھ بھی شامل کرنے سے پہلے جانچنا مناسب ہے۔

[Service]
Restart=on-failure
RestartSec=15

مقررہ نیند ایک جال کیوں ہے

ExecStartPre میں نیند ترتیب کی اصلاح جیسی محسوس ہوتی ہے اور اضافی قدموں والی تاخیر کی طرح برتاؤ کرتی ہے۔ یہ ہر بوٹ کو سست کرتی ہے، ان کو بھی جو صحت مند تھے، اور جب لنک آپ کے منتخب کردہ عدد سے زیادہ وقت لے تو پھر بھی ہار جاتی ہے۔

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

جب ترتیب درست ہو اور نام پھر بھی ناکام ہوں

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

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