SSTP पहले सर्वर को प्रमाणित करता है और बाद में उपयोगकर्ता को

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

एक विश्वसनीय प्रमाणपत्र एंडपॉइंट को साबित करता है; खाते के बारे में यह कुछ नहीं कहता।

TLS हैंडशेक क्या स्थापित करता है

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

इसलिए लॉगिन प्रॉम्प्ट तक पहुँचने के लिए प्रमाणपत्र जाँच हटाना गलत सुधार है। आपको ऐसे कनेक्शन पर लॉगिन प्रॉम्प्ट मिलता है जिसे आप सत्यापित नहीं कर सकते। प्रमाणपत्र त्रुटि होस्टनाम, घड़ी, श्रृंखला या ट्रस्ट कॉन्फ़िगरेशन की है।

SSTP और PPP ऊपर क्या जोड़ते हैं

SSTP HTTPS पर चलता है और अपने अंदर PPP ले जाता है, कनेक्शन के चारों ओर अपने नियंत्रण आदान-प्रदान के साथ। फिर PPP अपने लिंक और प्रमाणीकरण चरण चलाता है, और प्रमाणीकरण विधि सर्वर नीति और क्लाइंट क्षमता पर निर्भर करती है। PAP, CHAP, MS-CHAPv2 और EAP सभी बहुत अलग गुणों वाले PPP प्रमाणीकरण विकल्प हैं। VPN का उपयोगकर्ता जाँच वही PPP चरण है, उसके नीचे की TLS परत नहीं।

इसलिए उपयोगकर्ता अस्वीकृति का अर्थ क्रेडेंशियल, खाता प्रतिबंध या विधि बेमेल हो सकता है।

सर्वर पक्ष का कारण प्रोफ़ाइल का हर रहस्य रीसेट करने से कहीं अधिक उपयोगी है। खाता अक्षम होने की घटना और विधि बातचीत की विफलता क्लाइंट पर समान दिखती हैं और सर्वर पर उनमें कुछ भी साझा नहीं है।

त्रुटि को चरण से मिलाएँ

जाँचें कि कनेक्शन TLS तक पहुँचता है, फिर SSTP HTTP आदान-प्रदान, फिर PPP चरण। पुनः प्रयासों के बीच लॉग के टाइमस्टैम्प संरेखित रखें ताकि पहली विफलता बाद की सफलता से न भ्रमित हो। एक विंडो में दो प्रयास लॉग करने वाला क्लाइंट अन्यथा ऐसा दिखेगा कि वह अपने पहुँचे अंतिम चरण में विफल हुआ। अंतिम पंक्ति नहीं, पहली प्रासंगिक त्रुटि पढ़ें।

वही संरेखण सर्वर पक्ष पर मायने रखता है, जहाँ प्रमाणीकरण रिकॉर्ड और परिवहन लॉग अक्सर अलग घड़ियों वाली अलग फ़ाइलें होती हैं। दो मिनट का अंतर स्पष्ट कारण को असंभव दिखाने के लिए पर्याप्त है।

लॉगिन के बाद, प्राधिकरण अभी भी अलग है

सफल लॉगिन हर निजी संसाधन नहीं देता। रूट तय करते हैं कि क्या पहुँचा जा सकता है, DNS तय करता है कि क्या हल होता है, और हर सेवा अभी भी अपनी अनुमतियाँ लागू करती है। जुड़ा दिखने वाला सत्र टनल के बारे में कथन है, फ़ाइल साझा के बारे में नहीं। जब उपयोगकर्ता जुड़ सकता है और एक होस्ट तक नहीं पहुँच सकता, तब टनल चरण पहले ही समाप्त हो चुका है।

यह वही स्तरीकरण है जो हैंडशेक ने दिखाया, एक स्तर ऊपर।

खाता पुनर्प्राप्ति को ऑपरेटर की समर्थित प्रक्रिया में रखें, स्पष्ट उपयोगकर्ता अस्वीकृति के जवाब में परिवहन सेटिंग्स बदलने के बजाय। अक्षम खाते को ठीक करने के लिए परिवहन बदलना उस तरह का सुधार है जो तब काम करता दिखता है जब खाता किसी असंबंधित कारण से फिर सक्षम किया जाता है।