अपयशानंतर Windows VPN संवाद उघडा आणि तो तुम्हाला एक क्रमांक आणि एक वाक्य देतो, त्यातील वाक्य सहसा कमी उपयुक्त अर्धा भाग असतो। क्रमांक सांगतो की जोडणीचा कोणता टप्पा अयशस्वी झाला, आणि टप्पा ठरवतो की पुढे कोणता लॉग, कोणती सेटिंग आणि कोणता संघ पाहायचा। टप्पे क्रमाने पार करायला सुमारे दहा मिनिटे लागतात आणि ज्याला कधीही डायल करण्याची परवानगी नव्हती असे खाते दुरुस्त करण्यासाठी ॲडॉप्टर पुन्हा इन्स्टॉल करणे, प्रोटोकॉल बदलणे आणि स्टॅक रीसेट करणे हा परिचित क्रम टाळतात।

क्रमांकाला टप्पा म्हणून वाचा

स्थानिक जोडणी चार टप्प्यांतून जाते। ती सर्व्हरपर्यंत पोहोचते आणि दुवा स्थापित करते, सुरक्षेबद्दल बोलणी करते, वापरकर्त्याची प्रमाणीकरण करते, आणि पत्ते व मार्गदर्शन लागू करते। त्यांपैकी प्रत्येकातील अपयश वेगळे पुरावे सोडते, आणि एका टप्प्याचा कोड इतरांबद्दल काही उपयुक्त सांगत नाही।

टाळायची चूक म्हणजे कोडला तीव्रतेचा दर्जा मानणे। दुव्याचे अपयश आणि अधिकृततेचे अपयश दोन्ही "जोडता आले नाही" असे वाचले जातात, आणि त्याशिवाय त्यांच्यात काही समान नाही। तीव्रता सांगते की किती तातडीचे आहे; टप्पा सांगतो की काय उघडायचे।

Code familyStageWhere the evidence lives
829, 703Link or dial completionClient event log, remote listener reachability
720PPP negotiation and miniport bindingAdapter state, bindings, client log detail
691, 649, 812Identity and authorizationGateway or authentication server decision
Connected, no trafficAddressing, routing and resolutionRoute 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 त्रुटी व्यापते, आणि कोणत्याही शाखेला काहीही पुन्हा इन्स्टॉल करण्याची गरज नसते। संवाद नेहमी सांगत होता की तुमच्याकडे कोणता आहे; काम हे आहे की त्या सर्वांना एकच समस्या मानण्यास नकार देणे।

संबंधित लेख