कॉर्पोरेट 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 आणि स्वयं-शोध स्थिती, नंतर अ‍ॅपची स्वतःची प्रॉक्सी हाताळणी. तुमच्या गृहीतकापेक्षा वेगळे असलेल्या पहिल्यावर थांबा.

इथला प्रत्येक प्रसंग कॉन्फिगरेशन प्राधान्याचा प्रश्न आहे. कोणतेही टनेल तुमचे टूल बिघडवत नाही.