دوبارہ شروع کرنے کے بعد VPN سرور کی بحالی کی جانچ کریں: پہلے کیا دیکھیں

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

چار مالک، چار مختلف جانچیں

دوبارہ شروع کرنے سے پہلے طے کریں کہ ٹنل کو کیا واپس لانا ہے۔ آپ جو جانچ چلاتے ہیں اور جو اصلاح لگاتے ہیں دونوں اسی جواب پر منحصر ہیں، اور چار عام مالک ہوتے ہیں: VPN ڈیمن کے لیے ایک systemd unit، WireGuard انٹرفیس کے لیے ایک wg-quick مثال unit، ایک کنٹینر رن ٹائم، یا نیٹ ورک مینیجر پروفائل۔ اگر مالک کا نام نہ بتا سکیں تو رک جائیں اور اسے تلاش کریں، کیونکہ متوقع اسٹارٹ اپ راستے کے بغیر دوبارہ شروع کرنے کی جانچ صرف یہ بتاتی ہے کہ کچھ ہوا۔

ہر مالک اپنی ترتیب کہیں اور رکھتا ہے۔ systemd کے زیرِ انتظام OpenVPN سرور شروع ہوتے وقت اپنی ترتیب پڑھتا ہے، اس لیے بوٹ کے وقت فائل میں جو ہو وہی چلتا ہے۔ wg-quick انٹرفیس اپنے پتے، راستے اور DNS اسی فائل سے لیتا ہے، یعنی وہ انٹرفیس جو شیل سے ہاتھ سے اوپر اٹھایا گیا اور کبھی unit کے طور پر فعال نہیں کیا گیا وہ واپس نہیں آئے گا۔ کنٹینر اپنا انٹری پوائنٹ واپس لاتا ہے لیکن میزبان کے فائر وال تبدیلیاں نہیں، سوائے اس کے کہ وہ کنٹینر سے باہر ہوں۔

پہلے بنیادی حالت، ورنہ نتیجے کا کوئی مطلب نہیں

کام کرتے وقت کارآمد حالت ریکارڈ کریں: ٹنل پر پتے، کلائنٹ سب نیٹ کے راستے، NAT یا فارورڈنگ قواعد، سننے والا ساکٹ، اور فارورڈنگ sysctl۔ ip addr show wg0، ip route، nft list ruleset یا iptables-save، ss -lunp اور sysctl net.ipv4.ip_forward زیادہ تر میزبانوں پر کافی ہیں۔

یہ نہیں کہ سروس چل رہی ہے، بلکہ یہ ریکارڈ کریں کہ اسے کس طرح شروع ہونے کے لیے ترتیب دیا گیا ہے۔ systemctl is-enabled wg-quick@wg0 اور systemctl is-active wg-quick@wg0 مختلف سوالات کے جواب دیتے ہیں، اور بوٹ کے وقت فعال حالت ہی اہم ہے، جیسا کہ systemctl(1) میں بیان ہوا ہے۔ OpenVPN کے لیے دیکھیں کہ میزبان کون سا ٹیمپلیٹ استعمال کرتا ہے، کیونکہ openvpn@server اور openvpn-server@server مختلف ڈیفالٹس والے مختلف unit ہیں۔

دوبارہ شروع کرنے کا عمل چلائیں اور پہلی ناکامی پڑھیں

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

ٹنل ناقابل استعمال ہونے کے باوجود ڈیمن فعال ہو سکتا ہے، اور یہی سب سے عام غلط کامیابی ہے۔ اگر unit صرف network.target کا انتظار کرے، network-online.target کا نہیں، تو نیٹ ورک آن لائن ہونے سے پہلے اسٹارٹ اپ مکمل ہو سکتا ہے۔ حوالہ شدہ فائلیں جیسے سرٹیفکیٹ، چابیاں یا CRL اس وقت ناقابلِ مطالعہ ہو سکتی ہیں، کیونکہ ماؤنٹ یا رازوں کا راستہ ابھی تیار نہیں۔ unit کا جرنل پڑھنے تک دونوں میں سے کوئی مسئلہ systemctl status میں ظاہر نہیں ہوتا۔

میزبان سے باہر سے جانچیں۔ اسی LAN کا کلائنٹ ایسے راستے سے کامیاب ہو سکتا ہے جو کوئی دور دراز کلائنٹ کبھی استعمال نہ کرے، اور مشین تک SSH سیشن ٹنل کے بارے میں کچھ ثابت نہیں کرتا۔ جڑیں، اندرونی نام حل کریں، نجی وسیلے تک پہنچیں، پھر منسوخی کی حالت اور چابیاں ابھی کارآمد ہیں اس کی تصدیق کے لیے ایک بار پھر جڑیں۔

آپ کی اصلاح کا تعین کرنے والی تین شرطیں

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

اصلاح وہیں کریں جہاں ترتیب کی ملکیت ہے۔ فارورڈنگ کو sysctl drop-in میں رکھیں، NAT قواعد کو بوٹ پر لوڈ ہونے والے قواعد کے مجموعے میں رکھیں، unit کو شروع کرنے کے بجائے فعال کریں، اور راز ایسے راستے پر رکھیں جو unit شروع ہونے سے پہلے موجود ہو۔ unit میں نیند شامل کرنا انحصار کو ظاہر کرنے کے بجائے چھپاتا ہے۔

نتیجہ runbook میں ریکارڈ کریں

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

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