SSTP, HTTPS पर PPP है, पोर्ट 443 पर कोई वेब पेज नहीं

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 और सर्वर-पक्ष अग्रेषण तय करते हैं कि उपयोगकर्ता कहाँ तक पहुँच सकता है। सुरंग एक मार्ग है, अनुमति नहीं।