ब्राउजरको 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 ले गर्ने सबैबाट अलग गर्छ। होस्टनामलाई आफ्नो अन्त्य बिन्दुले बदल्नुहोस् र यसले छाप्ने subject र शृंखला पढ्नुहोस्।
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 पासवर्ड रिसेट नगर्नुहोस्, किनकि प्रमाणहरू कहिल्यै मागिएनन्।