कर्पोरेट 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 र वंशानुगत प्रोक्सी र एपको पूर्वनिर्धारित मिलेर एकैचोटि तीन सम्भावित कारण दिन्छन्।

हरेक परीक्षणमा एउटा चर राख्नुहोस् र तपाईंले प्रयोग गरेको गन्तव्य होस्ट नोट गर्नुहोस्। त्यो आधाररेखा बिना अर्को व्यक्तिले चारै चरण सुरुदेखि दोहोर्याउँछ।