TLS की जाँच करने वाले प्रॉक्सी के पीछे SSTP: सत्र कहाँ टूटता है

आपका ब्राउज़र कॉर्पोरेट इंट्रानेट लोड करता है, प्रॉक्सी प्रमाणपत्र पर भरोसा है, और फिर भी SSTP क्लाइंट कनेक्शन के अंत के पास गिर जाता है। यह पैटर्न गलत पासवर्ड नहीं, बल्कि वेब अनुरोध और टनल किए गए सत्र के अंतर की ओर इशारा करता है। कनेक्शन को TCP से ऊपर तक देखें और पहला विफल चरण नोट करें। चरण, त्रुटि कोड नहीं, बताता है कि प्रॉक्सी कारण है या नहीं।

जहाँ क्लाइंट रुकता है वहीं से शुरू करें

क्लाइंट एक निश्चित क्रम से गुजरता है: पोर्ट 443 पर TCP कनेक्शन, TLS हैंडशेक, प्रमाणपत्र सत्यापन, SSTP का HTTP आदान-प्रदान, PPP बातचीत और प्रमाणीकरण, फिर IP कॉन्फ़िगरेशन। हर चरण पर विफलता अलग छाप छोड़ती है, और उन्हें मिला देने से आप गलत कॉन्फ़िगरेशन पृष्ठ पर पहुँचते हैं।

TCP विफलता किसी भी TLS बाइट के आने से पहले टाइमआउट या रीसेट है। TLS विफलता चेतावनी या हैंडशेक टाइमआउट है। प्रमाणपत्र विफलता श्रृंखला या नाम के बारे में चेतावनी देती है। HTTP विफलता सफल हैंडशेक के बाद आती है, अक्सर स्थिति कोड या तुरंत बंद होने के रूप में। PPP विफलता टनल तकनीकी रूप से स्थापित होने के बाद आती है, इसलिए वह प्रमाणीकरण की समस्या जैसी दिखती है।

पहली त्रुटि पंक्ति के बजाय क्लाइंट लॉग में अंतिम सफल चरण पढ़ें। त्रुटि पंक्ति आमतौर पर परिणाम बताती है, जबकि चरण की सीमा उस घटक का नाम लेती है जिसने मना किया।

SSTP नेटवर्क से क्या ढोने को कहता है

SSTP TCP 443 पर TLS के ऊपर चलता है और फिर SSTP विनिर्देश में परिभाषित SSTP_DUPLEX_POST नामक HTTP अनुरोध /sra_{GUID}/ के रूप के पथ पर भेजता है। अनुरोध व्यावहारिक रूप से असीमित सामग्री लंबाई घोषित करता है और सत्र के पूरे जीवनकाल में स्ट्रीम को दोनों दिशाओं में खुला रखता है। PPP फ़्रेम उसी स्ट्रीम के भीतर चलते हैं।

इसीलिए सामान्य ब्राउज़िंग संभालने वाला प्रॉक्सी भी विफल हो सकता है। सीमित बॉडी वाला GET या POST बफ़र, जाँच और आगे भेजा जा सकता है; कभी न खत्म होने वाली बॉडी वाली डुप्लेक्स स्ट्रीम नहीं। बॉडी पूरी होने का इंतज़ार करने वाला प्रॉक्सी हमेशा इंतज़ार करता है, और क्लाइंट अंत में टाइमआउट हो जाता है।

विधि फ़िल्टरिंग और प्रमाणीकरण अपने-अपने विफलता ढंग जोड़ते हैं। अगर प्रॉक्सी अनुरोध के लिए क्रेडेंशियल मांगता है, तो ब्राउज़र उत्तर देता भी, पर VPN क्लाइंट शायद न दे। अगर वह विधि हटाता या फिर से लिखता है, तो गेटवे PPP शुरू होने से पहले अनुरोध ठुकरा देता है।

जाँच पहचान क्यों बदलती है

TLS की जाँच करने वाला प्रॉक्सी क्लाइंट का TLS कनेक्शन समाप्त करता है और गेटवे तक अलग कनेक्शन खोलता है। इसलिए क्लाइंट गेटवे का नहीं, प्रॉक्सी का प्रमाणपत्र सत्यापित करता है, और गेटवे प्रॉक्सी को अपना साथी मानता है। जब संगठन अपनी जड़ वितरित करता है, तो ब्राउज़र और VPN क्लाइंट दोनों उस श्रृंखला को स्वीकार कर सकते हैं, इसलिए हैंडशेक सफल होता है और समस्या अगले चरण पर चली जाती है।

सफल सत्यापन का मतलब यह नहीं कि प्रॉक्सी सत्र ढो सकता है। उसे अब भी बिना बफ़रिंग के असीमित द्विदिश POST रिले करना है और दोनों कनेक्शन घंटों तक जीवित रखने हैं। कई जाँच उत्पाद अनुरोध-प्रतिक्रिया ट्रैफ़िक के लिए बने हैं और इस मामले को खराब तरीके से संभालते हैं या बिल्कुल नहीं।

इसीलिए अज्ञात जड़ जोड़ना या सत्यापन बंद करना गलत मरम्मत है। यह बदलता है कि क्लाइंट कौन-सा प्रमाणपत्र स्वीकार करता है; सत्र को वास्तव में तोड़ने वाले स्ट्रीम प्रबंधन के बारे में यह कुछ नहीं करता।

सेटिंग्स बदलने से पहले जारीकर्ता पहचानें

एंडपॉइंट से पूछें कि वह कौन-सा प्रमाणपत्र प्रस्तुत करता है और उस पर किसने हस्ताक्षर किए। नीचे दिए कमांड VPN सत्र शुरू किए बिना श्रृंखला और जारीकर्ता दिखाते हैं:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

अगर जारीकर्ता सार्वजनिक CA है, तो इस होस्ट के लिए कनेक्शन संभवतः अवरोधित नहीं है और विफलता कहीं और है। अगर जारीकर्ता संगठन का अपना CA है, तो जाँच सक्रिय है और गेटवे तक प्रॉक्सी के ज़रिए पहुँचा जाता है। सिर्फ़ नाम से निष्कर्ष निकालने से पहले फ़िंगरप्रिंट की तुलना नेटवर्क टीम की अपेक्षा से करें।

उसी होस्ट पर ब्राउज़र परीक्षण केवल यह साबित करता है कि प्रॉक्सी GET स्वीकार करता है। यह SSTP विधि, अनुरोध URI या बॉडी के जीवनकाल के बारे में कुछ नहीं कहता, इसलिए काम करते इंट्रानेट पृष्ठ को टनल पथ समर्थित होने का प्रमाण न मानें।

समर्थित पथ चुनें

नेटवर्क मालिक से एक ठोस सवाल पूछें: क्या प्रॉक्सी इस गेटवे पर पोर्ट 443 पर बिना बफ़र वाला डुप्लेक्स POST अनुमत करता है? हाँ का मतलब प्रॉक्सी में अपवाद या VPN होस्ट के लिए दस्तावेज़ी बायपास है। नहीं का मतलब है कि जाँचा गया पथ SSTP नहीं ढो सकता, और समर्थित सुधार क्लाइंट की छेड़छाड़ नहीं, बल्कि दूसरा पथ या प्रोटोकॉल है।

विकल्पों में आमतौर पर VPN गेटवे के लिए बिना जाँच वाला निकास, केवल कॉर्पोरेट ट्रैफ़िक प्रॉक्सी से भेजने वाला स्प्लिट-टनल डिज़ाइन, या संगठन द्वारा किसी दूसरे पोर्ट पर समर्थित वैकल्पिक प्रोटोकॉल शामिल होते हैं। हर एक नेटवर्क डिज़ाइन का हिस्सा है, और हर एक को उसी डिवाइस और प्रोफ़ाइल के साथ परखा जाना चाहिए ताकि तुलना पथ को अलग करे।

नतीजा दर्ज करें: जारीकर्ता, विफल चरण, प्रॉक्सी नियम और चुना गया पथ। अगला व्यक्ति जो 98 प्रतिशत पर वही रुकावट देखेगा, पूरी यात्रा दोहराने के बजाय एक तथ्य जाँच सकेगा।