Windows VPN त्रुटि कोड: कौन-सा चरण विफल हुआ, और क्या लॉग करें
829, 703, 720, 691, 649: हर संख्या एक चरण का नाम बताती है, और हर चरण के अपने प्रमाण हैं। एक प्रयास दर्ज करें, गेटवे लॉग की तुलना करें, एक परत बदलें।
विफलता के बाद Windows VPN संवाद खोलें और वह आपको एक संख्या और एक वाक्य देता है, जिसमें वाक्य आमतौर पर कम उपयोगी आधा होता है। संख्या बताती है कि कनेक्शन का कौन-सा चरण विफल हुआ, और चरण तय करता है कि आगे कौन-सा लॉग, कौन-सी सेटिंग और कौन-सी टीम देखनी है। चरणों को क्रम से पार करने में लगभग दस मिनट लगते हैं और यह उस परिचित क्रम को रोकता है जिसमें एडाप्टर फिर से इंस्टॉल करने, प्रोटोकॉल बदलने और स्टैक रीसेट करने से ऐसा खाता ठीक किया जाता है जिसे कभी डायल करने की अनुमति ही नहीं थी।
संख्या को एक चरण के रूप में पढ़ें
मूल कनेक्शन चार पड़ावों से गुजरता है। यह सर्वर तक पहुँचकर लिंक स्थापित करता है, सुरक्षा पर बातचीत करता है, उपयोगकर्ता को प्रमाणित करता है, और पता तथा रूटिंग लागू करता है। इनमें से हर एक में विफलता अलग प्रमाण छोड़ती है, और एक चरण का कोड दूसरों के बारे में कुछ उपयोगी नहीं कहता।
जिस गलती से बचना है वह है कोड को गंभीरता का दर्जा मानना। लिंक विफलता और प्राधिकरण विफलता दोनों "कनेक्ट नहीं हो सका" के रूप में पढ़ी जाती हैं, और उसके अलावा उनमें कुछ समान नहीं है। गंभीरता बताती है कि कोई बात कितनी तात्कालिक है; चरण बताता है कि क्या खोलना है।
| Code family | Stage | Where the evidence lives |
|---|---|---|
| 829, 703 | Link or dial completion | Client event log, remote listener reachability |
| 720 | PPP negotiation and miniport binding | Adapter state, bindings, client log detail |
| 691, 649, 812 | Identity and authorization | Gateway or authentication server decision |
| Connected, no traffic | Addressing, routing and resolution | Route table and resolver configuration |
पहला चरण: लिंक और डायल प्रयास
829 का अर्थ है कि अंतर्निहित लिंक टूट गया। यह नहीं बताता कि दूरस्थ साथी ने जवाब देना बंद किया, किसी बीच के बॉक्स ने सत्र समाप्त किया, या क्लाइंट पर नीति ने उसे बंद किया। 703 जैसा डायल-पूर्णता कोड और भी पहले का है: प्रयास लिंक तक कभी पहुँचा ही नहीं, जो आमतौर पर प्रोफ़ाइल, सेवा की स्थिति या स्थानीय नीति की ओर इशारा करता है।
Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message
इवेंट क्वेरी वह हिस्सा है जिसे लोग छोड़ देते हैं। समय-चिह्न और इंटरफ़ेस नाम वाला क्लाइंट-पक्ष रिकॉर्ड संवाद से अधिक मूल्यवान है, क्योंकि यह बताता है कि प्रयास मशीन से बाहर निकला भी या नहीं। रिकॉर्ड नहीं और सुनने वाले की प्रतिक्रिया नहीं का अर्थ है पहुँच की समस्या, और क्लाइंट में कोई भी बदलाव इसे नहीं बदलता।
अगर वही प्रोफ़ाइल किसी दूसरे नेटवर्क पर काम करती है, तो यहीं रुकें। कोड कॉन्फ़िगरेशन त्रुटि नहीं बल्कि मार्ग की स्थिति बता रहा है, और अगली उपयोगी तुलना दो कैप्चर हैं, दूसरी पुनर्स्थापना नहीं।
दूसरा चरण: PPP और मिनीपोर्ट बाइंडिंग
720 लिंक और उपयोगकर्ता के बीच होता है। टनल ऊपर आया और फिर PPP परत किसी पता या नियंत्रण प्रोटोकॉल पर बातचीत नहीं कर सकी, जो अक्सर क्लाइंट पर बाइंडिंग की समस्या है, अस्वीकृत क्रेडेंशियल नहीं। यही अंतर कोड का पूरा मूल्य है: यह कहता है कि क्रेडेंशियल तक कभी पहुँचा ही नहीं गया, इसलिए खाता संदिग्ध नहीं है।
Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled
उन दोनों आउटपुट को पढ़ना कुछ भी रीसेट करने से अधिक जानकारी देता है। मौजूद पर शुरू न हुआ मिनीपोर्ट, या किसी अन्य सॉफ़्टवेयर द्वारा अक्षम प्रोटोकॉल बाइंडिंग, ठीक इसी चरण की विफलता पैदा करते हैं। दोनों को स्टैक के बाकी हिस्से को छुए बिना ठीक किया जा सकता है। इसके विपरीत, पूर्ण रीसेट उस पता और फ़िल्टर स्थिति को हटा देता है जिसका खराबी से कोई संबंध नहीं था।
तीसरा चरण: पहचान और प्राधिकरण
691 का अर्थ है कि क्रेडेंशियल अस्वीकार किए गए। 649 का अर्थ है कि खाते को डायल करने की अनुमति नहीं है, और 812 का अर्थ है कि दूरस्थ पहुँच नीति ने कनेक्शन अस्वीकार किया। ये निर्णय हैं, परिवहन खराबी नहीं, और क्लाइंट केवल इनकी रिपोर्ट कर सकता है।
प्रमाण दूसरी तरफ़ है। गेटवे ऑपरेटर से उस समय-चिह्न का प्रयास और मेल खाने वाली नीति माँगें; निर्देशिका के मालिक से पूछें कि खाते के पास डायल-इन अनुमति है या नहीं और वह नीति के अपेक्षित समूह में है या नहीं। टनल का प्रकार बदलना या क्लाइंट फिर से इंस्टॉल करना पहचान के बारे में लिए गए निर्णय को नहीं बदल सकता।
इस चरण में उपयोगी आदत है टिकट में सटीक खाता स्ट्रिंग लिखना, किसी भी डोमेन उपसर्ग सहित। 691 के आश्चर्यजनक रूप से कई मामले गलत डोमेन के लिए सहेजे गए क्रेडेंशियल होते हैं, और यह प्रोटोकॉल सेटिंग्स में नहीं बल्कि खाता स्ट्रिंग में दिखता है।
चौथा चरण: जुड़ा हुआ, और कुछ भी काम नहीं करता
कनेक्शन पूरा हो सकता है और फिर भी बेकार रह सकता है। उसके पास पता होता है, क्लाइंट सफलता बताता है, और एप्लिकेशन का हर अनुरोध समय-सीमा पार कर जाता है। संवाद में कुछ भी इसे नहीं दर्शाता, और देखने के लिए कोई कोड नहीं है। उस बिंदु पर संवाद समाप्त हो चुका है और उपयोगी प्रमाण कहीं और है।
Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445
अगर मार्ग नहीं है, तो सर्वर ने उसे धकेला नहीं या क्लाइंट ने उसे गिरा दिया। अगर मार्ग है और नाम विफल होता है, तो समस्या रिज़ॉल्यूशन की है। अगर दोनों काम करते हैं और एप्लिकेशन फिर भी विफल होता है, तो आप टनल से आगे एप्लिकेशन के अपने कॉन्फ़िगरेशन में हैं।
प्रत्येक परीक्षण के लिए बदलाव एक ही परत में रखें। अगले प्रयास से पहले किया गया हर संपादन अगले कोड के संदर्भ का हिस्सा बन जाता है, और आपके अंतिम संपादन का वर्णन करने वाला कोड कोड के बिना होने से भी बुरा है।
एक प्रयास, एक बदलाव, एक रिकॉर्ड
चरण जो भी हो, रिकॉर्ड में कोड, संदेश, प्रोफ़ाइल का नाम, समय-चिह्न और वह नेटवर्क होना चाहिए जिस पर आप थे। पाँच फ़ील्ड, और उनमें से हर एक पहले से संवाद या क्लाइंट लॉग में आपके सामने है। यह समूह टिकट में चिपकाने के लिए काफ़ी छोटा और किसी और के दोबारा बनाने के लिए काफ़ी विशिष्ट है।
फिर उस समय-चिह्न को दूसरी तरफ़ के रिकॉर्ड के बगल में रखें। इस पृष्ठ के शीर्ष के पास की तालिका बताती है कि हर असंगति किस चरण की है। दूसरे रिकॉर्ड के बिना कोड केवल खोज सीमित करता है; उसके साथ चरण तय हो जाता है। तुलना ही वह चीज़ है जो संख्या को अनुमान नहीं बल्कि निदान में बदलती है।
वह आदत Windows के लगभग हर मूल VPN दोष को कवर करती है, और किसी भी शाखा में कुछ भी फिर से इंस्टॉल करने की आवश्यकता नहीं होती। संवाद हमेशा बता रहा था कि आपके पास कौन-सा है; काम इस बात में है कि उन सबको एक ही समस्या मानने से इनकार किया जाए।