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 की समस्या-निवारण मार्गदर्शिका, उदाहरण के लिए, व्यापक रीसेट लिखने के बजाय बाइंडिंग समस्याओं को पता-आवंटन समस्याओं से अलग करती है, और यह इस परिवार के हर कोड के लिए सही सहज ज्ञान है। सबसे चौड़े उपलब्ध औज़ार तक पहुँचने से पहले पढ़ें कि कोड क्या दावा करता है।