SSTP भनेको HTTPS माथिको PPP हो, पोर्ट 443 को वेब पृष्ठ होइन
TLS र एउटा HTTP अनुरोधले च्यानल खोल्छन्, त्यसपछि नियन्त्रण सन्देशहरू र PPP ले बाँकी गर्छन्। चरणहरू हिँडेर ब्राउजर परीक्षणले किन यति थोरै प्रमाणित गर्छ हेर्नुहोस्।
SSTP ले PPP लाई HTTPS जडानभित्र बोक्छ, त्यसैले बीचमा रहेको जुनसुकै कुरालाई यो वेब ट्राफिकजस्तो देखिन्छ। TLS र HTTP ले बाहिरी च्यानल स्थापित गर्छन्, त्यसपछि SSTP नियन्त्रण सन्देशहरूले सुरुङ तयार गर्छन्, र PPP ले सत्रको व्यवहार दिन्छ। उही ठेगानामा पृष्ठ लोड गर्ने ब्राउजरले पहिलो चरणको एउटा भाग मात्र पूरा गरेको हुन्छ। यसलाई VPN परीक्षण मान्नु भनेको काम गरिरहेको प्रोक्सीलाई प्रोटोकल नमिलेको दोष लगाउने तरिका हो।
चारै चरण क्रममा हिँड्नुहोस्, र तपाईंले देखेको खराबी तीमध्ये एउटामा पर्नेछ।
चरण 1: TCP र TLS
क्लाइन्टले पोर्ट 443 मा TCP जडान खोल्छ र TLS ह्यान्डसेक गर्छ। प्रमाणपत्र शृंखला क्लाइन्ट कन्फिगर गरिएको होस्टनामसँग मिल्नुपर्छ। यहाँ नाम नमिल्दा कुनै पनि SSTP सन्देश आदानप्रदान हुनुअघि खराबी हुन्छ, र SSTP विनिर्देश ले यो बाहिरी HTTPS च्यानल पहिले नै अवस्थित छ भनी मान्छ। पछिल्ला चरणहरूमा केहीले पनि यहाँको विश्वास खराबीको भरपाई गर्न सक्दैन।
साधारण वेब सर्भरले यो चरण पूर्ण रूपमा पूरा गरेर पनि अर्कोमा असफल हुन सक्छ। TLS को सफलता प्रमाणपत्रको प्रमाण हो, त्यसपछाडिको प्रोटोकलको होइन।
चरण 2: HTTPS अनुरोध
SSTP ले आफ्नो अनुरोध विशेष विधि, SSTP_DUPLEX_POST बाट गर्छ र कागजात फर्काउनुको सट्टा आदानप्रदान खुला राख्छ। साधारण पृष्ठ अनुरोधका लागि कन्फिगर गरिएको सर्भर वा प्रोक्सीले जडान स्वीकार गरेर पछि विधि अस्वीकार गर्न सक्छ। त्यही अस्वीकार नै मानिसहरूले सामान्यतया पोर्ट 443 अवरुद्ध भएको भनी वर्णन गर्ने अनुकूलता समस्या हो।
सर्भर लगमा प्रतिक्रिया कोड र विधि पढ्नुहोस्। यो चरणको अस्वीकार TCP समय समाप्तिभन्दा फरक समस्या हो, र दुवैले फरक सुधारतर्फ लैजान्छन्।
चरण 3: नियन्त्रण सन्देशहरू
अनुरोध स्वीकार भएपछि, SSTP ले सुरुङबारे वार्ता गर्ने र तयार पार्ने नियन्त्रण सन्देशहरू आदानप्रदान गर्छ। यी HTTP अनुरोध होइनन्, HTTPS मुख्य भागभित्रका प्रोटोकल सन्देश हुन्, त्यसैले मुख्य भाग जाँचेर पुनःलेखन गर्ने प्रोक्सीले पृष्ठ अनुरोध अछुतो राखेर यिनलाई तोड्न सक्छ।
यहीँ गहिरो जाँचको बीच उपकरणले आफ्नो प्रतिष्ठा कमाउँछ। पृष्ठ लोड हुन्छन् तर VPN असफल हुन्छ भने, पोर्ट खुला छ कि भनेर होइन, मुख्य भाग बदलिँदै छ कि भनेर जाँच्नुहोस्।
चरण 4: PPP ले नियन्त्रण लिन्छ
त्यसपछि PPP ले सत्रको व्यवहार दिन्छ: लिङ्क वार्ता, प्रमाणीकरण र त्यसपछिको सञ्जाल तहको कन्फिगरेसन। PPP प्रमाणीकरण क्लाइन्टले पहिले नै पार गरेको TLS जाँचभन्दा अलग छ। क्लाइन्टले स्वीकार गर्ने सर्भर प्रमाणपत्रले प्रयोगकर्ताको प्रमाणहरू मान्य छन् कि खाता अधिकृत छ भन्नेबारे केही भन्दैन।
स्वीकार गरिएको प्रमाणपत्र र अस्वीकार गरिएको लगइन परस्पर विरोधी हुँदैनन्। यी स्वतन्त्र नतिजा भएका क्रमिक चरणहरू हुन्।
प्रमाणीकरणका धेरै भूमिका छन्
क्लाइन्टले TLS सर्भरको पहिचान आफ्नो विश्वास भण्डार र कन्फिगर गरिएको नामसँग जाँच्छ। त्यसपछि PPP ले परिनियोजनअनुसार प्रयोगकर्ता वा मेसिनको प्रमाणीकरण गर्छ। सर्भरले को जोडिन सक्छ र कहाँसम्म पुग्न सक्छ भन्नेबारे आफ्नै नीति थप्न सक्छ। होस्टनामलाई प्रमाणपत्रको पहिचानसँग मिलाएर राख्नुहोस्, किनकि कच्चा ठेगाना राख्दा काम गर्ने सेटअप नाम-जाँच खराबीमा परिणत हुन्छ।
कुन चरणले खराबी रिपोर्ट गर्यो लेख्नुहोस्। प्रमाणपत्र, विधि, नियन्त्रण सन्देश, PPP प्रमाणीकरण, त्यसपछि मार्गहरू: पाँच ठाउँ, पाँच सुधार।
ब्राउजर परीक्षणले के देखाउन सक्छ र के सक्दैन
ठेगानामा पृष्ठ लोड गर्नुले DNS समाधान, TCP पहुँच र HTTP बोल्ने केही सुनिरहेको छ भनी प्रमाणित गर्छ। विधि स्वीकार भयो, नियन्त्रण आदानप्रदान टिक्यो वा PPP प्रमाणीकरण कन्फिगर भयो भनी प्रमाणित गर्दैन। पोर्ट बदलेर अर्को प्रोफाइल रूपान्तरण गर्नुको सट्टा SSTP लागू गर्ने क्लाइन्ट प्रयोग गर्नुहोस्।
सत्र सुरु भएपछि पनि मार्ग, DNS र सर्भर-पक्ष पठनले प्रयोगकर्ता कहाँसम्म पुग्न सक्छ भन्ने निर्धारण गर्छ। सुरुङ एउटा बाटो हो, अनुमति होइन।