जहाँ ब्राउज़र का HTTPS सफल होता है वहाँ SSTP विफल होता है: क्यों
SSTP पोर्ट 443 पर TLS के भीतर चलता है, लेकिन यह कोई वेब अनुरोध नहीं है। TCP, TLS पहचान, SSTP विनिमय और PPP प्रमाणीकरण को अलग-अलग चरणों के रूप में परखें।
ब्राउज़र VPN होस्टनाम को HTTPS पर बिना किसी शिकायत के खोलता है, और SSTP क्लाइंट फिर भी जुड़ने से इनकार करता है। उस जोड़ी में कुछ भी विरोधाभासी नहीं है। SSTP TLS को बाहरी परिवहन के रूप में उपयोग करता है और फिर उसी कनेक्शन के भीतर अपना अनुरोध और PPP पेलोड चलाता है, इसलिए पेज का सफल लोड केवल एक संकीर्ण बात साबित करता है: होस्ट पोर्ट 443 पर GET का उत्तर देता है। क्लाइंट कोई दूसरा प्रश्न पूछ रहा है, और सर्वर उसका उत्तर बुरी तरह दे सकता है।
पेज लोड होता है और टनल नहीं
लोग ब्राउज़र परीक्षण की ओर इसलिए भागते हैं क्योंकि यह तेज़ है, और फिर परिणाम को इस बात का प्रमाण मान लेते हैं कि सर्वर पहुँच योग्य और कॉन्फ़िगर है। यह उस पथ पर GET का प्रमाण है जो एड्रेस बार ने खोला, इससे अधिक कुछ नहीं। VPN बातचीत उसी TLS हैंडशेक के बाद शुरू होती है, लेकिन भेजती है ऐसी विधि और पथ जिनका वेब पेज कभी उपयोग नहीं करता। इसलिए ब्राउज़र के लिए 200 उत्तर इस बारे में कुछ नहीं कहता कि SSTP एंडपॉइंट मौजूद है या नहीं।
दोनों अवलोकनों को अलग करें और खोज छोटी हो जाती है। परिवहन और प्रमाणपत्र श्रृंखला काम करते हैं, और उनके ऊपर के प्रोटोकॉल विनिमय में कुछ काम नहीं करता। यह टूटे पोर्ट या समाप्त प्रमाणपत्र से अलग जाँच है, और इसके लिए अलग सबूत चाहिए।
SSTP क्लाइंट वास्तव में क्या भेजता है
क्लाइंट /sra_{GUID}/ पथ पर SSTP_DUPLEX_POST विधि के साथ HTTP अनुरोध भेजता है, फिर कनेक्शन के बॉडी को PPP फ्रेम ले जाने वाली द्विदिश धारा के रूप में खुला रखता है। अनुरूप सर्वर HTTP/1.1 200 का उत्तर देता है और वेब सर्वर जैसा व्यवहार करना बंद कर देता है। बाकी कुछ भी एक हस्ताक्षर है: 405 या 404 का अर्थ है एंडपॉइंट नहीं है, 301 या 302 का अर्थ है कोई चीज़ अनुरोध को पुनर्निर्देशित कर रही है, और तत्काल FIN का अर्थ है किसी प्रॉक्सी या सर्वर ने धारा बंद कर दी।
इसलिए लक्ष्य TLS प्रमाणपत्र जड़ा हुआ वेब सर्वर नहीं, बल्कि SSTP सर्वर होना चाहिए। विधि, पथ और दीर्घकालिक बॉडी प्रोटोकॉल की आवश्यकताएँ हैं, इसलिए रिवर्स प्रॉक्सी उन्हें केवल कॉन्फ़िगरेशन से नहीं जोड़ सकता। सामान्य HTTPS को पूरी तरह अग्रेषित करने वाली प्रॉक्सी फिर भी ऐसी विधि अस्वीकार कर सकती है जिसे वह नहीं पहचानती।
प्रॉक्सी या वेब सर्वर धारा कहाँ तोड़ता है
एक मध्यस्थ कुछ भी अग्रेषित करने से पहले HTTP अनुरोध पंक्ति की जाँच करता है, और असामान्य पथ वाली कस्टम विधि उसके नियमों में विफल हो सकती है। कुछ उपकरण सामान्य पेज परोसते हैं जबकि टनल को अस्वीकार या बाधित करते हैं, इसलिए क्लाइंट स्वच्छ इनकार के बजाय ऐसे कनेक्शन की रिपोर्ट करता है जो शुरू होकर मर जाता है। अन्य अनुरोध स्वीकार करते हैं, फिर बॉडी या निष्क्रियता का टाइमआउट लागू करते हैं जिसे PPP कीपअलाइव नहीं झेल सकते। क्लाइंट की ओर से दोनों एक जैसे दिखते हैं, इसलिए कौन-सा चरण विफल हुआ यह त्रुटि पाठ से अधिक महत्वपूर्ण है।
वेबसाइट और SSTP के बीच पोर्ट 443 साझा करना एक रूटिंग निर्णय है, यह वादा नहीं कि हर हॉप दोनों बातचीत को एक ही तरह संभालेगा। यदि पथ में लोड बैलेंसर, फ़ायरवॉल या TLS टर्मिनेटर है, तो VPN कॉन्फ़िगरेशन छूने से पहले उसे संदिग्ध सूची में जोड़ें।
चरणों को अलग-अलग परखें
जाँच क्रम से चलाएँ और पहली विफलता पर रुकें, क्योंकि हर चरण अलग परत को बाहर करता है। नीचे दी TLS प्रोब प्रमाणपत्र की पहचान को SSTP जो कुछ भी करता है उससे अलग करती है। होस्टनाम को अपने एंडपॉइंट से बदलें और जो सब्जेक्ट और श्रृंखला वह छापती है उसे पढ़ें।
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comफिर क्लाइंट त्रुटि से अनुमान लगाने के बजाय शेष सबूतों को चरणों से मिलाएँ। नीचे दी तालिका टिकट में उद्धृत करने के लिए चेकलिस्ट है, उस हस्ताक्षर के साथ जो एक विफलता को अगली से अलग करता है।
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
टिकट में "कनेक्ट नहीं हो सकता" लिखने के बजाय अंतिम सफल चरण दर्ज करें। MS-SSTP विनिर्देश TLS हैंडशेक के बाद आने वाले अनुरोध और PPP विनिमय का दस्तावेज़ीकरण करता है, और यही संदर्भ है कि ब्राउज़र परीक्षण दोनों में से किसी का विकल्प क्यों नहीं हो सकता।
पहले पहचान, फिर PPP
TLS पहचान और PPP प्रमाणीकरण क्रमिक हैं, वैकल्पिक नहीं, और इन्हें मिलाना लोगों को गलत सर्वर सेटिंग तक भेजता है। क्लाइंट पहले सर्वर प्रमाणपत्र और उसके इच्छित उद्देश्य को मान्य करता है, फिर PPP अपनी स्थिति पर बातचीत करता है और उपयोगकर्ता को चुनौती-प्रतिक्रिया विधि या EAP से प्रमाणित करता है। प्रमाणपत्र की समस्या अस्वीकृत पासवर्ड से भिन्न त्रुटि देती है, और कोई भी त्रुटि उस चरण का वर्णन नहीं करती जिसे दूसरी कवर करती है।
होस्टनाम को पते से बदलना, या प्रमाणपत्र चेतावनी को पार करके क्लिक करना, उस जाँच को हटा देता है जो विफल चरण की पहचान करती, उसे ठीक करने के बजाय। चेतावनी रखें और उसे पढ़ें। जब HTTP विनिमय कभी SSTP व्यवहार तक नहीं पहुँचा तो PPP पासवर्ड रीसेट न करें, क्योंकि क्रेडेंशियल कभी माँगा ही नहीं गया।