systemd VPN سروس بند کرتا ہے: Type= کو کلائنٹ سے ملائیں

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

کامیاب آغاز کے چند سیکنڈ بعد یونٹ غیر فعال کیوں ہو جاتی ہے

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

نیٹ ورک کنفیگریشن چھونے سے پہلے کلائنٹ کے رویے کے ساتھ یونٹ کی قسم پڑھیں۔

وہ قسم منتخب کریں جو کلائنٹ سے مطابقت رکھتی ہو

دو نمونے زیادہ تر وینڈر CLI ڈھانپ لیتے ہیں: ایک کمانڈ جو سیشن کنفیگر کر کے نکلتی ہے، اور ایک کمانڈ جو واپس آنے سے پہلے مددگار فورک کرتی ہے۔ ہر ایک کو مختلف یونٹ شکل درکار ہے۔

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot اور RemainAfterExit=true مل کر کمانڈ واپس آنے کے بعد بھی یونٹ کو فعال رکھتے ہیں، جو کنفیگر کرو اور نکلو نمونے سے مطابقت رکھتا ہے، اور اسٹاپ کمانڈ سروس کو صاف بندش دیتی ہے۔ فورک کرنے والا کلائنٹ وہی شکل رکھتا ہے مگر اسے Type=forking درکار ہے تاکہ systemd بچے کی پیروی کرے۔ Restart=on-failure، RestartSec=30 اور محدود StartLimitBurst مقرر کریں، تاکہ فراہم کنندہ کی رکاوٹ غلطی کو دفن کرنے والے ری اسٹارٹ لوپ میں نہ بدلے۔

نگرانی میں چلنے والے کلائنٹ کو کبھی ڈیمن بننے نہ دیں

systemd سے باہر کے نگران بھی اسی دیوار سے ٹکراتے ہیں۔ ڈیمن بنے کلائنٹ کو شروع کرنے والی runit رن اسکرپٹ فوراً نگران کے پاس واپس آتی ہے، جو اس واپسی کو کریش پڑھ کر ایک اور کاپی شروع کر دیتا ہے۔ ہر نگران سامنے والے عمل کی ملکیت کی توقع رکھتا ہے، جیسے sshd -D آگے رہتا ہے۔ نگرانی والی کمانڈز کے لیے ڈیمن پرچم ہٹا دیں اور پس منظر کا کام نگران کو دیں۔ جو ریپر اسکرپٹ ٹنل بننے سے پہلے واپس آتی ہیں وہ بھی وہی الجھن پیدا کرتی ہیں۔

جو عمل خود کو الگ کر لیتا ہے وہ ہر اس چیز کے لیے پوشیدہ ہے جسے اس پر نظر رکھنی تھی۔

سیشن ختم ہوتا ہے اور ٹنل کو ساتھ لے جاتا ہے

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

سروس کا صارف اسی مسئلے کا دوسرا نصف ہے۔ root کی ملکیت والی اور موڈ 0600 کی کلید کسی دوسرے اکاؤنٹ کے تحت چلنے والی یونٹ کے لیے ناقابل قرأت ہے، آپ کے شیل میں sudo نے جو بھی حاصل کیا ہو۔

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

پتہ بننے کے بعد منحصر یونٹوں کو ترتیب دیں

جب ڈیمن ایسے ٹنل پتے سے جڑتا ہے جو ابھی نہیں بنا، تو وہ Cannot assign requested address کے ساتھ نکل جاتا ہے۔ حل واضح ترتیب ہے، دوبارہ کوشش کا لوپ نہیں۔

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= کاموں کو ترتیب دیتا ہے، جبکہ ڈیوائس یونٹ پر Requires= منحصر کو انٹرفیس کی موجودگی سے باندھتا ہے، جو صرف نیٹ ورک ہدف کا انتظار کرنے سے زیادہ مضبوط ہے۔ تدوین کے بعد مینیجر دوبارہ لوڈ کریں اور منحصر سروس دوبارہ شروع کریں، پھر یہ ماننے کے بجائے کہ ترتیب کارگر ہوئی اس کا جرنل پڑھیں۔ کلائنٹ کا آؤٹ پٹ StandardOutput=journal یا لاگ آپشن کے ساتھ جرنل میں بھیجیں، کیونکہ نگرانی والا کلائنٹ جو ایسی فائل میں لکھتا ہے جسے کوئی نہیں کھولتا، بالکل ویسا ہی دکھتا ہے جیسا کبھی شروع ہی نہ ہوا ہو۔

پھر ایک بار ری بوٹ کریں اور تصدیق کریں کہ ٹنل ڈیوائس ظاہر ہونے کے بعد یونٹ فعال ہے۔ صرف systemctl start سے تصدیق شدہ درستی نے اس بوٹ ترتیب کی جانچ نہیں کی جسے درست کرنا تھا۔