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 र एपकै आफ्नै नेटवर्क सेटिङ हेर्नुहोस्। त्यो तेस्रो तह हो, र त्यो पनि प्रोक्सी फिल्ड होइन।