कर्पोरेट VPN जोडिँदा डिबग प्रोक्सी अन्धो हुन्छ

क्याप्चर उपकरण बिहानभर चल्छ, टनेल जोडिन्छ, अनि त्यो चुप हुन्छ। डिस्कनेक्ट गर्नुहोस् र फेरि सुरु हुन्छ। VPN ले प्रोक्सी बिगार्यो भन्ने पहिलो सोच आउँछ, तर प्रोक्सी कन्फिगरेसनमा वास्तवमै केही बदलिएको छैन। बदलिएको कुरा यो हो कि एप्लिकेसनहरूले अहिले कुन कन्फिगरेसन पढ्छन्: टनेल प्रविष्टिले आफ्नै प्रोक्सी सेटिङ बोक्न सक्छ, व्यवस्थापित प्रोफाइलले स्वचालित कन्फिगरेसन फेरि खोल्न सक्छ, र केही रनटाइमले अपरेटिङ सिस्टमले दिने कुराको एउटा भाग मात्र पढ्छन्। विश्वव्यापी मान छुनुअघि प्रत्येक जडानको मान पढ्नुहोस्।

Windows ले प्रत्येक जडानका लागि छुट्टै प्रोक्सी राख्छ

इन्टरनेट विकल्पमा संवादमा उस्तै देखिने दुई तह छन्। स्थानीय सञ्जालका सेटिङ साधारण स्थानीय जडानमा लागू हुन्छन्, जबकि डायल-अप वा VPN प्रविष्टिले HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections मुनि आफ्नै प्रतिलिपि बाइनरी मानका रूपमा राख्छ। परिचित विश्वव्यापी रजिस्ट्री मान लेख्दा त्यो प्रतिलिपि अद्यावधिक हुँदैन।

उपकरणले जडानअघि ठीक र पछि गलत व्यवहार गर्ने ठ्याक्कै यही हो, र त्यसका सेटिङमा कतै देखिने परिवर्तन हुँदैन। तपाईं हेरिरहनुभएको संवाद स्थानीय सञ्जालको प्यानल थियो। त्यो सही थियो, र त्यो अप्रासंगिक थियो। Windows ले वास्तवमा प्रयोग गरेको प्रविष्टि टनेलका लागि बनाइएको प्रविष्टि थियो।

एउटा प्रविष्टि बदल्ने समर्थित तरिका WinINET जडान विकल्प API हो: जडानको नाम, फ्ल्याग, प्रोक्सी सर्भर र बाइपास सूचीसहित INTERNET_PER_CONN_OPTION_LIST भर्नुहोस्, लागू गर्नुहोस्, अनि रिफ्रेस गर्नुहोस्। छिटो जाँचका लागि टनेल प्रविष्टिको आफ्नै सेटिङ संवाद खोलेर त्यसको प्रोक्सी प्यानललाई स्थानीय सञ्जालको प्यानलसँग तुलना गर्नुहोस्; कहाँ हेर्ने भन्ने थाहा भएपछि फरक सामान्यतया स्पष्ट हुन्छ।

व्यवस्थापित PAC आफैं फेरि खुल्न सक्छ

macOS मा स्वचालित प्रोक्सी कन्फिगरेसन स्क्रिप्ट र प्रोक्सी स्वतः-पत्ता नेटवर्क सेवाका गुण हुन्, मेसिनका होइनन्। कन्फिगरेसन प्रोफाइलले तिनीहरूलाई अनिवार्य गर्न सक्छ, त्यसैले टिक हटाएपछि पनि तिनीहरू फेरि देखा पर्छन्, र त्यसपछि हरेक अनुरोध स्क्रिप्टले छान्ने प्रोक्सीमा जान्छ।

जाँच गर्नुहोस् र, अधिकृत भएमा, ट्राफिक बोक्ने सेवाका लागि ती दुई स्विच बन्द गर्नुहोस्:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

अनुमानको सट्टा सेवाको साँचो नाम प्रयोग गर्नुहोस्। Wi-Fi र USB इथरनेट एडाप्टर दुवै भएको ल्यापटपमा त्यस्ता दुई हुन्छन्, र तपाईंको ट्राफिक एउटाले मात्र बोक्छ। scutil --proxy हालको प्राथमिक सेवाका मान छाप्छ। प्रोफाइल जित्यो भन्ने निष्कर्षमा पुग्नुअघि त्यो आउटपुटलाई तपाईंले सम्पादन गरेकोसँग तुलना गर्नुहोस्।

उपकरणलाई साँचो अपस्ट्रिमतिर फर्काउनुहोस्

यदि स्क्रिप्टमा कर्पोरेट प्रोक्सी छ भने त्यो पढ्नुहोस् र त्यही ठेगाना क्याप्चर उपकरणभित्र बाह्य प्रोक्सीका रूपमा हाल्नुहोस्। त्यसपछि उपकरणले साँचो अपस्ट्रिमतिर पठाउँछ, कर्पोरेट प्रोक्सीले त्यही अपेक्षा गर्छ, र नीतिसँग लड्नुको सट्टा अनुरोधको बाटोमै रहन्छ।

पुनः कन्फिगर गर्नुको सट्टा डिबगिङमा राख्ने कदम यही हो।

प्रोक्सीलाई टनेलभित्र धकेल्नुहोस्

OpenVPN मा आधारित क्लाइन्टले टनेल उठेपछि लागू हुने प्रोक्सी विकल्प स्वीकार्न सक्छ, रुटहरू क्लाइन्टसँग हुँदा यो सुविधाजनक हुन्छ:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

यो विकल्पलाई आदर गर्ने क्लाइन्टले मात्र प्रयोग गर्नेछन्, र यसले तपाईंको सुन्ने पोर्ट प्रोफाइलमा कडा रूपमा लेख्छ। यसलाई तैनाथी मानक नभई प्रयोगशालाको सुविधा मान्नुहोस्, किनकि अर्को प्रोफाइल पुशले यसलाई हटाउनेछ।

केही क्लाइन्टले सिस्टम प्रोक्सी कहिल्यै पढ्दैनन्

Firefox ले आफ्नै प्रोक्सी सेटिङ राख्छ, त्यसैले सिस्टम प्रोक्सी प्रयोग गर्ने ब्राउजरले नगर्दा पनि यसले कहिलेकाहीँ क्याप्चर जारी राख्छ। स्वचालित कन्फिगरेसन नबुझ्ने पुरानो .NET क्लाइन्ट जहाँ पनि चले पनि सिधै जोडिन्छ, त्यसैले टनेल प्रविष्टिमार्फत लोड हुने पृष्ठ पनि एपभित्रै असफल हुन सक्छ।

नेटवर्क उपकरणका पनि आफ्नै कारण हुन्छन्। टनेल वा फोन टेथरिङमाथि अड्किने FTP सत्र प्रायः क्लाइन्टले वार्ता गर्ने सक्रिय विरुद्ध निष्क्रिय मोडको समस्या हो, र कुनै प्रोक्सी सेटिङले त्यो बदल्ने छैन।

कन्फिगरेसन पढ्नुहोस्, टगल होइन

यस क्रममा काम गर्नुहोस्: टनेल प्रविष्टिको आफ्नै प्रोक्सी मान, प्रति-सेवा PAC र स्वतः-पत्ताको अवस्था, अनि एपकै आफ्नै प्रोक्सी ह्यान्डलिङ। तपाईंको अनुमानभन्दा फरक पर्ने पहिलोमै रोकिनुहोस्।

यहाँको हरेक घटना कन्फिगरेसन प्राथमिकताको समस्या हो। कुनै पनि टनेल तपाईंको उपकरण बिगार्ने होइन।