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 प्रतिशतको त्यही रोकावट देख्दा पूरै यात्रा दोहोर्याउनुको सट्टा एउटा तथ्य जाँच्न सक्नेछ।