SSTP टाइमआउट या प्रमाणपत्र त्रुटि: दोनों में फ़र्क कैसे करें

SSTP कनेक्शन दो तरह से विफल होता है जो उपयोगकर्ता की कुर्सी से एक जैसे दिखते हैं, और हर एक की मरम्मत अलग परत पर होती है। टाइमआउट का मतलब है कि ज़रूरी अदला-बदली कभी पूरी नहीं हुई; प्रमाणपत्र त्रुटि का मतलब है कि पहचान की सामग्री आई और अस्वीकार कर दी गई। दूसरे को पहले जैसा मानने से आप उन फ़ायरवॉल और पासवर्ड की ओर जाते हैं जो कभी समस्या नहीं थे। फ़र्क बताने वाला सबूत क्लाइंट के अपने लॉग में है, अगर कुछ भी बदलने से पहले उसे पढ़ें।

दो विफलताएँ, दो अलग अदला-बदली

SSTP HTTPS के आकार के सत्र के अंदर सुरंग ले जाता है, इसलिए वह उन नेटवर्क में टिकता है जो 443 के अलावा कुछ नहीं देते। क्लाइंट TLS हैंडशेक पूरा करता है, प्रोटोकॉल-विशिष्ट विधि से HTTP अनुरोध भेजता है, और फिर सुरंग उसी स्ट्रीम के अंदर चलती है। इनमें से किसी भी चरण में विफलता कनेक्शन रोक देती है, और केवल बाद वाले चरण ही लॉगिन जानकारी से जुड़े हैं।

यही क्रम निदान है। अगर TLS हैंडशेक कभी पूरा न हो, तो कोई लॉगिन जानकारी नहीं भेजी गई, इसलिए पासवर्ड रीसेट मदद नहीं कर सकता। अगर हैंडशेक पूरा होकर फिर अटक जाए, तो पहचान स्वीकार हुई और अनुरोध के रास्ते में किसी चीज़ ने उसे ठुकरा दिया। अगर हैंडशेक सत्यापन संदेश के साथ विफल हो, तो सर्वर ने उत्तर दिया और क्लाइंट को जो सुना वह पसंद नहीं आया। तीन नतीजे, तीन परतें।

लॉग की पंक्ति आमतौर पर बताती है कि आप तीनों में से किसमें हैं, इसलिए पहले बदलाव से पहले उसे दर्ज करना उचित है।

टाइमआउट का मतलब है कि कोई चरण कभी पूरा नहीं हुआ

नाम-हल और TCP पहुँच से शुरू करें, क्योंकि वहाँ का टाइमआउट बाद के टाइमआउट जैसा ही दिखता है। 443 खुला बताने वाला पोर्ट चेकर केवल यह साबित करता है कि किसी श्रोता ने कनेक्शन स्वीकार किया, और उससे आगे कुछ नहीं।

अगला संदिग्ध मेज़बान नहीं, मार्ग है। प्रॉक्सी और एप्लिकेशन-समझदार फ़ायरवॉल कभी उस अनुरोध विधि को ठुकरा देते हैं जो SSTP इस्तेमाल करता है, या घंटों खुली रहने वाली स्ट्रीम गिरा देते हैं, और दोनों व्यवहार क्लाइंट की ओर से टाइमआउट जैसे लगते हैं। उसी मेज़बान द्वारा परोसा गया सामान्य HTTPS पृष्ठ पूरी तरह लोड होता है जबकि सुरंग विधि ठुकराई जाती है, इसलिए अंतिम बिंदु तक ब्राउज़ करना बहुत कम साबित करता है। उन दो स्थितियों को अलग करने के लिए प्रॉक्सी के बिना किसी नेटवर्क से परखें।

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

साथी की किसी भी प्रतिक्रिया से पहले का टाइमआउट खाते के बारे में कुछ नहीं कहता, और उस समय पासवर्ड बदलना केवल एक चर जोड़ता है।

प्रमाणपत्र त्रुटि का मतलब है कि पहचान ठुकराई गई

यहाँ सर्वर ने वाकई उत्तर दिया, इसलिए नेटवर्क काम कर रहा है और सवाल पहचान की ओर बढ़ता है। जिस नाम से क्लाइंट डायल करता है उसकी तुलना उन नामों से करें जिनका प्रमाणपत्र वाकई दावा करता है, फिर वैधता तिथियाँ और जारीकर्ता श्रृंखला जाँचें।

जिस निजी CA पर क्लाइंट भरोसा नहीं करता, वह उसी श्रेणी की त्रुटि पैदा करता है जो समाप्त प्रमाणपत्र पैदा करता है, और कई घंटे ग़लत चलती घड़ी भी। कच्चे पते पर डायल करना नई बेमेल पैदा करता है, क्योंकि प्रमाणपत्र नामों का दावा करता है, पतों का नहीं। प्रबंधित परिनियोजन में, त्रुटि पृष्ठ द्वारा दिए गए प्रतिस्थापन मूल को स्वीकार करने के बजाय उसके प्रशासक से इच्छित भरोसा कॉन्फ़िगरेशन लें। कारण ठीक करते समय सत्यापन चालू रहे।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

सफल TLS चरण को उसके पार होने के बाद अक्षत रखें, क्योंकि बाद में उसे पलटना छिपा देता है कि किस बदलाव ने सुरंग वाकई ठीक की।

जहाँ दोनों उलझ जाते हैं

दोनों विफलताएँ ऐसे कनेक्शन के रूप में दिखती हैं जो उठता नहीं, और दोनों तब आती हैं जब उपयोगकर्ता ने कुछ असंबंधित बदल दिया हो। यही संयोग ग़लत मरम्मत को कुछ समय के लिए विश्वसनीय बनाता है।

दो आदतें इन्हें अलग रखती हैं। कॉन्फ़िगरेशन छूने से पहले क्लाइंट लॉग दर्ज करें, ताकि पहली स्थिति बची रहे। हर प्रयास में एक परत बदलें, ताकि अगला नतीजा किसी ज्ञात चर का हो। पोर्ट चेकर और ब्राउज़र पूरा क्रम नहीं, आंशिक अवलोकन हैं, और इनमें से कोई क्लाइंट की अपनी रिपोर्ट का विकल्प नहीं है। दोनों आदतों में से किसी का ख़र्च नहीं, और दोनों जाँच को छोटा करती हैं।

प्रमाणपत्र का सवाल और पहुँच का सवाल किसी कारण से अलग दर्ज किए गए हैं।

असली क्लाइंट से फिर परखें, फिर अंदर की ओर बढ़ें

ठीक-ठीक सुधार हो जाने पर ब्राउज़र टैब से नहीं, असली SSTP क्लाइंट और सही प्रोफ़ाइल से फिर कोशिश करें।

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

अगर सत्र जुड़ता है और संसाधन फिर भी विफल होते हैं, तो सुरंग अब संदिग्ध नहीं है: रूटिंग, DNS और सेवा-पहुँच की ओर बढ़ें। यह अलग सबूतों वाली अलग जाँच है। काम करने वाले TLS और प्रमाणीकरण चरण बनाए रखने से यह पहली की पुनरावृत्ति नहीं बनती। जो चरण विफल हुआ उसे टिकट में लिखें, वरना अगला व्यक्ति फिर ऊपर से शुरू करेगा।