Windows میں نیٹ ورک ری سیٹ VPN خرابی سے زیادہ مٹاتا ہے
ری سیٹ اڈیپٹرز، روٹس اور WFP فلٹرز صاف کرتا ہے، صرف ناکام ٹنل نہیں۔ پروفائل، سرٹیفکیٹ فہرست اور شواہد محفوظ کریں، پھر تہوں میں جانچیں۔
مشورہ ہر Windows VPN شکایت کے بعد دس منٹ میں آتا ہے: نیٹ ورک ری سیٹ چلائیں، یہ سب ٹھیک کر دیتا ہے۔ نہیں کرتا، اور یہ تنگ نہیں ہے۔ وہ بٹن اڈیپٹرز صاف کرتا ہے، پروٹوکول دوبارہ باندھتا ہے، جامد پتے اور طے شدہ روٹس ہٹاتا ہے، فائر وال اور فلٹر اندراجات پھینکتا ہے، اور ساتھ ہی Wi-Fi پروفائلز بھی بھول جاتا ہے۔ ایسی مشین پر جس میں چلنے والی مگر غلط کنفیگر ٹنل ہو، یہ ایک قابل تشخیص خرابی کو غیر دستاویزی دوبارہ تعمیر میں بدل دیتا ہے۔ پہلے پانچ چیزیں محفوظ کریں، اور آپ اسے واپس کرنے کا اختیار برقرار رکھیں گے۔
ری سیٹ VPN پروفائل تک محدود نہیں
VPN کنکشن نیٹ ورک اسٹیک بانٹنے والی بہت سی چیزوں میں سے ایک ہے۔ اڈیپٹر ہٹانا اور دوبارہ شامل کرنا انٹرفیس انڈیکس بدلتا ہے، اور جو بھی اس انڈیکس کی طرف اشارہ کرتا تھا، روٹ سے فائر وال قاعدے تک اور تیسرے فریق کے فلٹر ڈرائیور تک، اب ایسی چیز کی طرف اشارہ کرتا ہے جو مزید موجود نہیں۔
ورچوئلائزیشن اسے مزید بگاڑتی ہے۔ Hyper-V سوئچز، VMware پل، کنٹینر نیٹ ورکس اور اپنے ورچوئل اڈیپٹر رکھنے والے VPN کلائنٹس سب ایک ہی جگہ رہتے ہیں۔ ایسا ری سیٹ جو بنیادی اسٹیک دوبارہ انسٹال کرے وہ ان اجزا کو آدھا موجود چھوڑ سکتا ہے، اور نتیجے میں بننے والی مشین چلتی ہوئی ہارڈ ویئر کی رپورٹ دیتی ہے بغیر کسی چلتی ہوئی راہ کے۔
ان میں سے کوئی بھی کبھی ری سیٹ نہ کرنے کے خلاف دلیل نہیں۔ یہ پہلے ری سیٹ کرنے کے خلاف دلیل ہے، ایسی مشین پر جسے آپ نے دستاویز نہیں کیا، جب اصل خرابی ایک روٹ اندراج یا ایک پرانا فلٹر ہو سکتی ہے۔ ری سیٹ ایک وسیع اوزار ہے جس کی کامیابی کی شرح تنگ ہے، اور اسے پہلا قدم بنانا اس بات کی ضمانت دیتا ہے کہ آپ کبھی نہیں جان سکیں گے کہ دونوں میں سے کون سی بات تھی۔
ترتیبات محفوظ کرنے سے پہلے شواہد محفوظ کریں
ناکامی بذات خود ڈیٹا ہے۔ درست ایرر کوڈ، وقت، کون سا پروفائل منتخب تھا، اور آیا گیٹ وے نے کوئی کوشش درج کی، لکھیں۔ وہ کوڈ جو کہے ٹنل کو کبھی جواب نہیں ملا اور وہ کوڈ جو کہے تصدیق ناکام ہوئی، بالکل مختلف مرمتوں کی طرف اشارہ کرتے ہیں۔ ری سیٹ کے بعد ممکن ہے آپ دونوں میں سے کوئی بھی دوبارہ پیدا نہ کر سکیں۔ خراب حالت کو ایسے اثاثے کی طرح سمجھیں جو آپ ابھی خرچ کرنے والے ہیں۔
حالت کو اسی وقت محفوظ کریں جب وہ ابھی خراب ہے، مشین کی عارضی ڈائریکٹریوں سے باہر کسی فولڈر میں:
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xmlآخری کمانڈ وہی ہے جو لوگ چھوڑ دیتے ہیں، اور اکثر وہی خرابی کی وضاحت کرتی ہے۔ ہٹائے گئے کلائنٹ کے بچے ہوئے فلٹرز مستقل پالیسی کے طور پر زندہ رہتے ہیں، اور ایکسپورٹ شدہ XML ان کا واحد مقامی ریکارڈ ہے۔ اسے پڑھیں اس سے پہلے کہ ری سیٹ وہ چیز مٹا دے جسے آپ شناخت کرنے کی کوشش کر رہے تھے۔
وہ کنفیگریشن محفوظ کریں جو واپس نہیں آئے گی
کچھ ترتیبات خودبخود دوبارہ بن جاتی ہیں۔ جامد پتے، حسب ضرورت روٹس، DNS لاحقے، پراکسی استثنائیں اور فائر وال قواعد نہیں بنتیں۔ خود پروفائلز بھی نہیں، جو فون بک فائل میں رہتے ہیں جسے ری سیٹ آپ کے لیے بحال نہیں کرتا۔
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfterسرٹیفکیٹ فہرست ظاہر سے زیادہ اہم ہے۔ کلائنٹ سرٹیفکیٹ نیٹ ورک ری سیٹ سے تباہ نہیں ہوتے، لیکن فہرست بتاتی ہے کہ پروفائل کا ان پر انحصار تھا اور آیا کوئی جلد ختم ہو رہا ہے۔ دوبارہ تعمیر کے بعد ختم شدہ سرٹیفکیٹ دریافت کرنا دوبارہ تعمیر ضائع کرتا ہے۔
شروع کرنے سے پہلے بحالی کا راستہ لکھیں
اگر مشین دور ہے اور VPN آپ کا داخلے کا واحد راستہ ہے، ری سیٹ آپ کا سیشن ختم کر سکتا ہے اور ممکن ہے موقع پر کسی شخص کے بغیر واپسی کا کوئی راستہ نہ ہو۔ اڈیپٹرز کو چھونے والی کوئی بھی چیز چلانے سے پہلے تصدیق کریں کہ بینڈ سے باہر رسائی موجود ہے یا کوئی شخص دستیاب ہے۔
انسٹالرز اور کنکشن کی تفصیلات ایسی جگہ رکھیں جہاں مشین بعد میں بھی ان تک پہنچ سکے۔ ایسا کلائنٹ جسے ٹنل کے ذریعے قابل رسائی وینڈر پورٹل سے دوبارہ انسٹال کرنا پڑے، ایک دائرہ وار انحصار ہے، اور یہی اس طریقہ کار کے سروس بندش بننے کا سب سے عام طریقہ ہے۔
پھر لکھیں کہ آپ کیا کر رہے ہیں اور کیوں، درست کمانڈز سمیت۔ اگلے شخص کو جاننا ہوگا کہ ری سیٹ تجربہ تھا یا فیصلہ، اور «ہم نے سب کچھ آزمایا» کوئی ریکارڈ نہیں۔
ری سیٹ کے بعد تہوں میں جانچیں
ایک وقت میں بہت کچھ بحال کرنا نتیجہ ناقابلِ مطالعہ بنا دیتا ہے۔ نیچے سے کام کریں: اڈیپٹر اور پتہ، پھر ناموں کا حل، پھر ٹنل کا شناختی مرحلہ، پھر ایپلیکیشن۔ ہر تہہ کے پاس ایسی کمانڈ ہے جو اس کے اپنے سوال کا جواب دیتی ہے:
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443اگر اڈیپٹر کی تہہ صحت مند ہے اور حل نہیں، رکیں اور حل درست کریں۔ اس موقع پر VPN کلائنٹ دوبارہ انسٹال کرنا ایک متغیر بڑھاتا ہے اور ایک سراغ ہٹاتا ہے۔ صرف وہی ترتیبات بحال کریں جن کی آپ وضاحت کر سکیں، ایک ایک کر کے، اور ہر ایک کے بعد وہی تہہ جانچیں۔
مائیکروسافٹ کی اپنی ٹربل شوٹنگ رہنمائی ایرر 720 کے لیے، مثلاً، عمومی ری سیٹ تجویز کرنے کے بجائے بنڈنگ مسائل کو پتہ تقسیم کے مسائل سے الگ کرتی ہے، جو اس خاندان کے ہر کوڈ کے لیے درست فطرت ہے۔ دستیاب سب سے وسیع اوزار تک پہنچنے سے پہلے پڑھیں کہ کوڈ کیا دعویٰ کرتا ہے۔