कॉर्पोरेट 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 आणि वारसा मिळालेली प्रॉक्सी आणि ॲपचे डीफॉल्ट एकत्र तीन संभाव्य कारणे देतात.

प्रत्येक चाचणीत एक चल ठेवा आणि तुम्ही वापरलेला गंतव्य होस्ट नोंदवा. त्या आधाररेषेशिवाय पुढची व्यक्ती चारही पायऱ्या सुरुवातीपासून पुन्हा करते.