VPN سرور کو رسائی پیچھے چھوڑے بغیر ریٹائر کرنے کا طریقہ

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

پہلے کلائنٹ فہرست سے گزریں

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

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

شناخت منسوخ کریں، صرف فائل نہیں

دو مختلف کارروائیوں کو دونوں منسوخی کہا جاتا ہے۔ WireGuard میں peer کی اجازت صرف اس وقت ہوتی ہے جب اس کی عوامی چابی peer کے حصے میں AllowedIPs اندراج کے ساتھ ظاہر ہو، اس لیے لیپ ٹاپ سے کنفگ فائل حذف کرنے سے سرور پر کچھ نہیں بدلتا۔ peer بلاک ہٹائیں اور فائل دوبارہ لاگو کریں، ان peerوں کو چھوڑے بغیر جو آپ رکھ رہے ہیں، جیسا کہwg(8) بیان کرتا ہے:

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf وہ حصہ ہے جو آپ کو دیکھ بھال کی کھڑکی بچاتا ہے۔ یہ انٹرفیس کو وہیں فائل سے دوبارہ بناتا ہے، اس لیے ایک peer ہٹانے سے وہ ٹنل نہیں ٹوٹتی جو باقی سب استعمال کر رہے ہیں۔ اگر آپ ایک peer کی بجائے پورا ہوسٹ ریٹائر کر رہے ہیں، تو ترتیب پھر بھی اہم ہے، کیونکہ وہ چابیاں کہیں اور قابل اعتماد ہو سکتی ہیں۔

X.509 ترتیب میں منسوخی کا قدم سرٹیفکیٹ ہے، فائل نہیں: openssl ca -revoke client.crt اور پھر openssl ca -gencrl -out crl.pem۔ اس کا اثر صرف وہاں ہوتا ہے جہاں تصدیق کنندہ اسے پڑھتا ہے، یعنیOpenVPN سرور جس میں crl-verify ترتیب دیا گیا اور بعد میں دوبارہ لوڈ کیا گیا۔ اگر یہ گیٹ وے اس CA کا واحد صارف ہے تو جس دن یہ مرتا ہے CRL کی اہمیت ختم ہو جاتی ہے؛ اگر وہی CA دوسرے گیٹ وے کے لیے دستخط کرتا ہے تو جو سرٹیفکیٹ آپ نے کبھی منسوخ نہیں کیا وہ وہاں کام کرتا رہتا ہے۔

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

سننے والوں اور ان تک جانے والے راستوں کو بند کریں

سروس کو اس طرح روکیں کہ وہ ری بوٹ کے بعد بھی قائم رہے، پھر یونٹ کی حالت کی بجائے ساکٹ فہرست سے تصدیق کریں۔ systemctl disable --now wg-quick@wg0 انٹرفیس روکتا ہے اور wg-quick کے شامل کردہ راستے اور قواعد ہٹاتا ہے؛ systemctl disable --now openvpn-server@server ٹیمپلیٹ والے OpenVPN مثال کے لیے یہی کرتا ہے۔ دونوں میں سے کسی کے بعد ss -lunp اور ss -ltnp چلائیں۔ پرانے پورٹ کے لیے خالی نتیجہ ہی واحد ثبوت ہے جو شمار ہوتا ہے۔

جو wg-quick نے شامل کیا، wg-quick ہٹا دیتا ہے۔ جو آپ نے ہاتھ سے شامل کیا وہ رہتا ہے: مستقل NAT قاعدہ، فائر وال میں اجازت، روٹر پر پورٹ فارورڈ، کلاؤڈ سیکیورٹی گروپ میں ingress قاعدہ، لوڈ بیلنسر کا سننے والا۔ انہیں واضح طور پر ہٹانا پڑتا ہے، اور DNS ریکارڈ کو بھی، یعنی A، AAAA اور نام کی طرف اشارہ کرنے والا کوئی بھی CNAME۔ جو نام مرے ہوسٹ کی طرف حل ہوتا ہے وہ اس نام سے مختلف طریقے سے ناکام ہوتا ہے جو حل ہی نہیں ہوتا، اور یہ فرق کسی کی دوپہر لے جائے گا۔

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

اس کا پیچھا کریں جو اب بھی پرانے اینڈ پوائنٹ کی طرف اشارہ کرتا ہے

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

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

تصدیق کریں، پھر لکھیں

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

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

ٹکٹ بند کرنے سے پہلے:

• کلائنٹ پروفائل ہٹائے یا بدلے گئے، نامعلوم ڈیوائس نمٹائے گئے
• peer ہٹائے گئے اور کنفگ دوبارہ لاگو ہوئی، یا سرٹیفکیٹ منسوخ کیے گئے اور CRL شائع ہوا
• ڈائریکٹری اکاؤنٹس بند کیے گئے، صرف مقامی فائلیں حذف نہیں کی گئیں
• سروس بند، پرانے پورٹ پر کوئی سننے والا نہیں بچا
• فائر وال، پورٹ فارورڈ، سیکیورٹی گروپ اور DNS اندراجات ہٹائے گئے
• بیک اپ لیبل کیے گئے، اسنیپ شاٹ بحالی کے راستوں سے خارج
• مانیٹرنگ اور آٹومیشن اسناد ریٹائر کی گئیں

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