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 और ऐप की अपनी नेटवर्क सेटिंग्स देखिए। यह तीसरी परत है, और वह भी प्रॉक्सी फ़ील्ड नहीं है।