जिथे ब्राउझरचे 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 पासवर्ड रीसेट करू नका, कारण ओळखपत्र कधीही मागितले गेले नाही।