Apple VPN प्रोफाइलमधील Proxy फील्ड प्रत्यक्षात काय करते
प्रॉक्सी फील्ड भरणे VPN ला HTTP बनवत नाही. यात दोन कनेक्शन सहभागी आहेत, आणि फील्ड त्यातील एकापर्यंतच पोहोचते.
Apple VPN कॉन्फिगरेशनमध्ये Proxy फील्ड भरणे म्हणजे टनेल वेब पोर्टमधून वळवले जाईल असे वाटते. पण तसे होत नाही. फील्ड सुसंगत अ‍ॅप तिथे पाठवायचे ठरवते त्या रहदारीसाठी अ‍ॅप्लिकेशन-स्तरावरील मध्यस्थ निवडते. मात्र VPN क्लायंटचे स्वतःच्या गेटवेसोबतचे कनेक्शन तुम्ही कॉन्फिगर केलेला प्रोटोकॉल, लिसनर आणि ट्रान्सपोर्ट ठरवतात, आणि हे वेगळे निर्णय आहेत.
दोन कनेक्शन, दोन मालक
अशा कोणत्याही रचनेत क्लायंटपासून गेटवेपर्यंतचे कनेक्शन आणि अ‍ॅपपासून गंतव्यापर्यंतचे कनेक्शन असते. Proxy विभाग दुसऱ्याबद्दल बोलतो, जरी तो पहिल्याच्याच प्रोफाइलमध्ये असला तरी.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple चा प्रॉक्सी सेटिंग्ज संदर्भ HTTP, HTTPS, SOCKS आणि स्वयंचलित प्रॉक्सी कॉन्फिगरेशनची यादी करतो, जे अ‍ॅप्सच्या प्रॉक्सी पर्यायांचे वर्णन आहे. यातील कोणतीही नोंद IPsec किंवा WireGuard पॅकेट गेटवेपर्यंत कसे पोहोचते हे सांगत नाही.
हा प्रश्न निकाली काढणारी एक झटपट तपासणी अशी आहे. VPN क्लायंट त्याच्या लॉगमध्ये जे पोर्ट आणि प्रोटोकॉल नोंदवतो ते सांगा. जर ती ओळ अजूनही UDP 500 किंवा UDP 51820 असे म्हणत असेल, तर प्रॉक्सी फील्डने त्यात काहीच बदलले नाही.
फील्ड केव्हा योग्य साधन आहे
प्रॉक्सी टनेलच्या पुढे उभा असलेला खरा प्रसंग आहे, पण ती प्रोफाइल फील्ड नसून क्लायंटची वैशिष्ट्ये आहे. OpenVPN चे पुस्तिका HTTP CONNECT प्रॉक्सीमधून नेल्या जाणाऱ्या TCP कनेक्शनसाठी --http-proxy चे दस्तऐवजीकरण करते. ते वापरण्यासाठी जुळणारा क्लायंट पर्याय, त्या मार्गाने पोहोचता येणारा गेटवे आणि वापरात असलेल्या पोर्टवर CONNECT ला परवानगी देणारा प्रॉक्सी लागतो.
तुमचा क्लायंट तो पर्याय देत असेल आणि नेटवर्क पोर्टवर CONNECT ला परवानगी देत असेल, तर ते चालू शकते. क्लायंट तो देत नसेल, तर सिस्टम प्रॉक्सी भरल्याने टनेलवर कोणताही परिणाम होत नाही.
केव्हा काहीच बदलत नाही
प्रॉक्सी फील्ड भरलेले असल्यामुळे IKEv2 किंवा IPsec प्रोफाइल HTTP टनेल होत नाही. WireGuard पण नाही, ज्याच्या कॉन्फिगरेशन स्वरूपात प्रॉक्सीची संकल्पनाच नाही. गेटवे पोर्ट बदलल्याने त्याचा प्रोटोकॉलही बदलत नाही. आणि सामान्य HTTPS ला उत्तर देणारा एंडपॉइंट आपोआप VPN लिसनर नसतो.
तीच जाळी जुन्या iPad मार्गदर्शकांमधून PPTP युगातील प्रोफाइल कॉपी करणाऱ्यांनाही अडकवते. पर्याय इंटरफेसमध्ये अजूनही आहेत; त्यांच्यामागील सेवा आता तो प्रोटोकॉल बोलत नाही.
कोणता स्तर दुरुस्त करायचा हे ठरवणे
काहीही बदलण्यापूर्वी कोणता स्तर अपयशी ठरला ते विचारा. क्लायंट सेशन प्रस्थापित करू शकत नसेल, तर समस्या ट्रान्सपोर्टमध्ये आहे आणि प्रॉक्सी फील्ड अप्रासंगिक आहे. टनेल चालू असूनही एक अ‍ॅप त्याच्या सर्व्हरपर्यंत पोहोचत नसेल, तर अ‍ॅप्लिकेशन प्रॉक्सी तपासण्यासारखा आहे. टनेल चालू असेल आणि सर्व अ‍ॅप्स अपयशी होत असतील, तर टनेलमधील राउटिंग आणि DNS संशयित आहेत.
पहिल्या प्रसंगासाठी, ऑपरेटरला विचारा की तो कोणता मंजूर पर्यायी ट्रान्सपोर्ट किंवा नेटवर्क समर्थित करतो. TCP 443 वर OpenVPN अस्तित्वात आहे कारण काही नेटवर्क फक्त त्यालाच परवानगी देतात, आणि त्यासाठी सर्व्हरने ते ऐकणे अजूनही आवश्यक आहे.
अवरोधित UDP पोर्टला तातडीच्या उपायाची परवानगी मानू नका. हँडशेक जुळवण्यासाठी गेटवेचे प्रमाणपत्र किंवा ओळख तपासण्या बंद करण्याऐवजी त्या अभंग ठेवा.
दोन्ही स्तर एकामागून एक तपासा
आधी टनेलची पुष्टी करा: क्लायंटच्या स्थिती पानावर प्रस्थापित सेशन आणि शून्य नसलेली बाइट गणना पहा. नंतर प्रॉक्सी सेटिंग थेट वाचा, प्रभावी कॉन्फिगरेशनसाठी scutil --proxy किंवा साठवलेल्या मूल्यासाठी networksetup -getwebproxy Wi-Fi वापरून. नंतर सिस्टम प्रॉक्सीचा आदर करणारे एक अ‍ॅप आणि ती दुर्लक्षित करणारे एक अ‍ॅप तपासा, कारण अनेक मूळ अ‍ॅप्स ती दुर्लक्षित करतात.
तीन निकाल, तीन वेगळ्या दुरुस्त्या.
दोन्ही स्तर यश नोंदवत असले तरी अ‍ॅप अपयशी होत असेल, तर स्प्लिट टनेलिंग, DNS आणि अ‍ॅपची स्वतःची नेटवर्क सेटिंग्ज पहा. तो तिसरा स्तर आहे, आणि तोही प्रॉक्सी फील्ड नाही.