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 त्रुटि समेट्छ, र कुनै पनि शाखाले केही पनि पुनः स्थापना गर्न आवश्यक ठान्दैन। संवादले सधैं तपाईंसँग कुन छ भनेर बताइरहेको थियो; काम भनेको ती सबैलाई एउटै समस्या मान्न नमान्नुमा छ।