कॉर्पोरेट VPN के पीछे ऐप के अनुरोध विफल होते हैं, पर ब्राउज़र काम करता है

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

वह अनुरोध देखें जो ऐप वास्तव में भेजता है

कॉन्फ़िगरेशन छूने से पहले ऐप से कहें कि वह क्या करता है। प्रॉक्सी को स्पष्ट रूप से बंद रखते हुए एक अनुरोध का कैप्चर और एक सादा पोर्ट परीक्षण आपको दो आधार-रेखाएँ देते हैं जिनसे आगे के चरणों की तुलना होती है। अगर प्रॉक्सी बंद होने पर अनुरोध सफल होता है, तो आप चार में से तीन परतें पहले ही पूरी कर चुके हैं।

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

आख़िरी दोनों को उसी गंतव्य पर चलाएँ और देखें कि वे कहाँ अलग होते हैं। काम करता ब्राउज़र और काम करता curl और काम न करता ऐप समस्या को उस चीज़ तक सीमित कर देते हैं जो ऐप जोड़ता है: एक प्रॉक्सी, एक ट्रांसपोर्ट या एक संदेश आकार।

ऐप को वह प्रॉक्सी विरासत में मिली जिसे किसी ने कॉन्फ़िगर नहीं किया

ज़्यादातर HTTP स्टैक डिफ़ॉल्ट रूप से ऑपरेटिंग सिस्टम से प्रॉक्सी कॉन्फ़िगरेशन पढ़ते हैं। कॉर्पोरेट VPN क्लाइंट अक्सर इसे अपनी एक्सेस प्रोफ़ाइल के हिस्से के रूप में इंस्टॉल करता है, इसलिए अनुरोध ऐसी प्रॉक्सी से बाहर जाते हैं जिसका ज़िक्र डेवलपर ने कोड में कभी नहीं किया। .NET में डिफ़ॉल्ट हैंडलर IE/WinHTTP सेटिंग्स से लेता है; Java -Dhttp.proxyHost पढ़ता है; Node में तब तक कोई अंतर्निहित प्रॉक्सी समर्थन नहीं है जब तक कोई लाइब्रेरी उसे न जोड़े। विफलता शायद ही कभी साफ़ इनकार होती है, इसीलिए लोग सर्वर की ओर देखने लगते हैं।

परीक्षण की लागत एक अनुरोध है: एक हैंडलर पर प्रॉक्सी स्पष्ट रूप से बंद करें और तुलना करें।

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

आपका चुना पोर्ट वह पोर्ट नहीं है जिसकी नीति अनुमति देती है

रूट किया गया होस्ट अनुमत सेवा नहीं है। कॉर्पोरेट नीति आमतौर पर बाहर जाने वाले वेब पोर्ट की अनुमति देती है और बाकी गिरा देती है, इसलिए 8080 या 1883 पर सेवा अगम्य है जबकि 443 ठीक काम करता है। ब्राउज़र यहाँ कुछ साबित नहीं करता: वह परिभाषा से 443 इस्तेमाल करता है।

उसी सेवा को 443 के पीछे प्रकाशित करें और अपवाद माँगने से पहले नाम से उस तक पहुँचें। अगर अपवाद वाकई ज़रूरी है, तो उसे एक स्रोत श्रेणी और एक गंतव्य तक सीमित रखें और उसे सेवा परिभाषा का हिस्सा मानें, किसी का निजी उपाय नहीं।

कच्चा TCP जिसे रास्ता रीसेट कर देता है

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

ट्रांसपोर्ट बदलें, फिर परीक्षण करें और उसी रन में कुछ और न बदलें। वह एक-चर परीक्षण आपको बताता है कि रीसेट रास्ते से आया या सेवा से।

वे कनेक्शन जो सिर्फ़ बड़े पेलोड पर बंद होते हैं

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

पेलोड को ऐप्लिकेशन परत पर टुकड़ों में बाँटें। इसे MTU के काम से अलग रखें: सुरंग का पैकेट आकार घटाना तब मदद करता है जब साधारण TCP सत्र एक स्थिर बाइट गिनती पर अटकते हैं, और यह मध्यस्थ द्वारा बहुत बड़े माने गए संदेश के लिए कुछ नहीं करता।

एक ही पास में चारों को कैसे अलग करें

तीन अवलोकन ज़्यादातर मामले सुलझा देते हैं। विफलता तुरंत होती है या सिर्फ़ बड़ी बॉडी के साथ? क्या वही अनुरोध प्रॉक्सी बंद होने पर सफल होता है? पोर्ट या ट्रांसपोर्ट बदलने पर परिणाम बदलता है? अगले बदलाव से पहले उत्तर लिख लें, क्योंकि कॉर्पोरेट VPN और विरासत में मिली प्रॉक्सी और ऐप का डिफ़ॉल्ट एक साथ तीन संभावित कारण देते हैं।

हर परीक्षण में एक चर रखें और जिस गंतव्य होस्ट का इस्तेमाल किया उसे दर्ज करें। उस आधार-रेखा के बिना अगला व्यक्ति चारों चरण शुरू से दोहराता है।