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 टक्के थांबा दिसल्यास संपूर्ण प्रवास पुन्हा करण्याऐवजी एक तथ्य तपासता येईल।