SSTP प्रथम सर्व्हर आणि नंतर वापरकर्त्याचे प्रमाणीकरण करते

SSTP क्लायंट TLS पूर्ण करू शकतो आणि तरीही एका सेकंदानंतर वापरकर्त्याला नाकारू शकतो। हा क्रम बग नाही, हा प्रोटोकॉल स्टॅक आहे: आधी वाहतूक सुरक्षा, नंतर वापरकर्ता प्रमाणीकरण। दोन्ही टप्पे वेगवेगळ्या संदेशांसह अयशस्वी होतात, म्हणून त्यांना वेगवेगळ्या दुरुस्त्याही लागतात। त्रुटी कोणत्या टप्प्याने निर्माण केली हे वाचणे हा निदानाचा मोठा भाग आहे।

विश्वासार्ह प्रमाणपत्र अंतिम बिंदू सिद्ध करते; खात्याबद्दल ते काहीही सांगत नाही।

TLS हस्तांदोलन काय स्थापित करते

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

म्हणूनच लॉगिन प्रॉम्प्टपर्यंत पोहोचण्यासाठी प्रमाणपत्र तपासण्या काढून टाकणे ही चुकीची दुरुस्ती आहे। तुम्हाला अशा कनेक्शनवर लॉगिन प्रॉम्प्ट मिळतो ज्याची तुम्ही पडताळणी करू शकत नाही। प्रमाणपत्र त्रुटी होस्टनाव, घड्याळ, साखळी किंवा विश्वास संरचनेशी संबंधित असते।

SSTP आणि PPP वर काय जोडतात

SSTP HTTPS वर चालते आणि आत PPP वाहून नेते, कनेक्शनभोवती स्वतःच्या नियंत्रण देवाणघेवाणीसह। नंतर PPP त्याचे लिंक आणि प्रमाणीकरण टप्पे चालवते, आणि प्रमाणीकरण पद्धत सर्व्हर धोरण आणि क्लायंट क्षमतेवर अवलंबून असते। PAP, CHAP, MS-CHAPv2 आणि EAP हे सर्व खूप वेगळ्या गुणधर्मांचे PPP प्रमाणीकरण पर्याय आहेत। VPN ची वापरकर्ता तपासणी तोच PPP टप्पा आहे, त्याखालील TLS स्तर नाही।

त्यामुळे वापरकर्ता नाकारणे म्हणजे क्रेडेन्शियल्स, खाते निर्बंध किंवा पद्धत विसंगती असू शकते।

सर्व्हर बाजूचे कारण प्रोफाइलमधील प्रत्येक रहस्य रीसेट करण्यापेक्षा खूप उपयुक्त आहे। खाते अक्षम होण्याची घटना आणि पद्धत वाटाघाटीचा अपयश क्लायंटवर सारखे दिसतात आणि सर्व्हरवर त्यांचे काहीही सामाईक नसते।

त्रुटी टप्प्याशी जुळवा

कनेक्शन TLS पर्यंत पोहोचते का, नंतर SSTP HTTP देवाणघेवाण, नंतर PPP टप्पा तपासा। पुन्हा प्रयत्नांमध्ये लॉगच्या वेळमुद्रा संरेखित ठेवा जेणेकरून आधीचे अपयश नंतरच्या यशाशी गोंधळणार नाही। एका विंडोमध्ये दोन प्रयत्न नोंदवणारा क्लायंट अन्यथा आपण पोहोचलेल्या शेवटच्या टप्प्यात अयशस्वी झाल्यासारखा दिसेल। शेवटची ओळ नाही, पहिली संबंधित त्रुटी वाचा।

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

लॉगिननंतरही अधिकृतता वेगळीच असते

यशस्वी लॉगिन प्रत्येक खाजगी संसाधन देत नाही। मार्ग काय पोहोचण्यायोग्य आहे हे ठरवतात, DNS काय सोडवले जाते हे ठरवते, आणि प्रत्येक सेवा अजूनही स्वतःच्या परवानग्या लागू करते। जोडलेले दाखवणारे सत्र सुरंगाबद्दलचे विधान आहे, फाइल शेअरिंगबद्दल नाही। जेव्हा वापरकर्ता कनेक्ट होऊ शकतो पण एका होस्टपर्यंत पोहोचू शकत नाही, तेव्हा सुरंगाचा टप्पा आधीच संपलेला असतो।

हे हस्तांदोलनाने दाखवलेले तेच स्तरविभाजन आहे, एक स्तर वर।

खाते पुनर्प्राप्ती ऑपरेटरच्या समर्थित प्रक्रियेत ठेवा, स्पष्ट वापरकर्ता नकाराला प्रतिसाद म्हणून वाहतूक सेटिंग्ज बदलण्याऐवजी। अक्षम खाते दुरुस्त करण्यासाठी वाहतूक बदलणे ही अशी दुरुस्ती आहे जी खाते असंबंधित कारणाने पुन्हा सक्षम केल्यावर काम करत असल्यासारखी वाटते।