SSTP पहिले सर्भर र पछि प्रयोगकर्ता प्रमाणित गर्छ

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

विश्वसनीय प्रमाणपत्रले अन्त्य बिन्दु प्रमाणित गर्छ; खाताबारे यसले केही भन्दैन।

TLS ह्यान्डसेकले के स्थापित गर्छ

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

त्यसैले लगइन प्रम्प्टसम्म पुग्न प्रमाणपत्र जाँच हटाउनु गलत सुधार हो। तपाईंले प्रमाणित गर्न नसक्ने जडानमा लगइन प्रम्प्ट पाउनुहुन्छ। प्रमाणपत्र त्रुटि होस्टनाम, घडी, चेन वा विश्वास कन्फिगरेसनसँग सम्बन्धित हो।

SSTP र PPP ले माथि के थप्छन्

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

त्यसैले प्रयोगकर्ता अस्वीकारको अर्थ प्रमाणहरू, खाता प्रतिबन्ध वा विधि बेमेल हुन सक्छ।

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

त्रुटिलाई चरणसँग मिलाउनुहोस्

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

त्यही पंक्तिबद्धता सर्भर पक्षमा पनि महत्त्वपूर्ण छ, जहाँ प्रमाणीकरण रेकर्ड र यातायात लग प्रायः फरक घडी भएका फरक फाइलहरू हुन्छन्। दुई मिनेटको फरक स्पष्ट कारणलाई असम्भव देखाउन पर्याप्त हुन्छ।

लगइनपछि पनि अधिकार अलगै हुन्छ

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

यो ह्यान्डसेकले देखाएको त्यही तहीकरण हो, एक तह माथि।

खाता पुनःप्राप्ति अपरेटरको समर्थित प्रक्रियाभित्र राख्नुहोस्, स्पष्ट प्रयोगकर्ता अस्वीकारको प्रतिक्रियामा यातायात सेटिङ बदल्नुको सट्टा। अक्षम खाता सुधार्न यातायात बदल्नु त्यस्तो सुधार हो जो खाता असम्बन्धित कारणले फेरि सक्षम हुँदा काम गरेजस्तो देखिन्छ।