iPhone VPN MTU: सङ्ख्या बदल्नु अघि मालिक निर्धारण गर्नुहोस्
तीन प्रश्नले एप, गेटवे प्रोफाइल वा फोनमा कोहीले पनि आकार बदल्न सक्छ कि भन्ने निर्धारण गर्छन्। Mac बाट सङ्ख्या उधारो लिनु अघि तिनका जवाफ दिनुहोस्।
iPhone VPN प्याकेट आकारबारे हरेक छलफल अन्ततः ppp0 नामको इन्टरफेसविरुद्ध त्यही Mac आदेश सुझाव दिन्छ, प्रायः साथमा एउटा सङ्ख्या हुन्छ। त्यो यहाँ लागू हुँदैन, र त्यो इन्टरफेस सम्बन्धित जडानको नभए Mac मा पनि त्यो सही नियन्त्रण हुँदैनथ्यो। फोनमा सङ्ख्या टनेल लागू गर्नेको हुन्छ: मूल प्रोफाइलका लागि अपरेटिङ सिस्टम, एपका लागि प्याकेट-टनेल प्रदायक, वा कागजात भएको विशेषता वार्ता हुँदा गेटवे। यीमध्ये कुन अवस्था हो भन्ने तीन प्रश्नले निर्धारण गर्छन्।
पहिलो प्रश्न: कुन क्लाइन्ट चलिरहेको छ
मूल IKEv2 प्रोफाइल, निर्मित Cisco IPsec प्रोफाइल र तेस्रो-पक्ष Cisco क्लाइन्ट तीन फरक कार्यान्वयन हुन्, प्रत्येकका समर्थित विशेषताका फरक सेट छन्। सेटिङमा भएको प्रोफाइल प्रकारले फोनले वास्तवमा कुन सुरु गर्यो भन्ने बताउँछ, र एप सूचीले मार्गमा प्रदायक छ कि छैन भन्ने बताउँछ। त्यहीँबाट सुरु गर्नुहोस्, किनकि बाँकी निर्णय त्यसैबाट आउँछ। एप सूचीमा कुनै प्रदायक नदेखिए टनेल अपरेटिङ सिस्टमको हो।
गेटवे विक्रेताबाट कार्यान्वयन अनुमान नगर्नुहोस्। Cisco हेडएन्डले विक्रेताको नामबाहेक केही साझा नगर्ने क्लाइन्टका जडान पनि अन्त्य गर्न सक्छ। पुरानो रिलिजको पुरानो बिल्डको स्क्रिनसटले त्यो जोडीले के समर्थन गर्थ्यो भन्ने बताउँछ, तपाईंको हातको फोनले के गर्छ भन्ने होइन।
दोस्रो प्रश्न: मान कसको हो
Apple ले नेटवर्क एक्सटेन्सन सेटिङ्स वस्तुबाट प्याकेट-टनेल विकासकर्तालाई MTU गुण देखाउँछ। यो आफ्नै टनेल कन्फिगर गर्ने प्रदायकका लागि API हो, प्रयोगकर्ता वा प्रशासकले अर्काको स्थापित क्लाइन्टमा खोल्न सक्ने स्विच होइन। तेस्रो-पक्ष एपले यसलाई देखाउन, बेवास्ता गर्न वा मान हार्ड-कोड गर्न रोज्न सक्छ।
मूल प्रोफाइलका लागि इन्टरफेसको आकार अपरेटिङ सिस्टमले छान्छ, र फोनले त्यसका लागि कुनै सम्पादक दिँदैन। Cisco टाढा-पहुँच गेटवेका लागि जडान प्रोफाइलको कागजात भएको विशेषता छ, र त्यो लागू हुन्छ कि हुँदैन क्लाइन्ट, रिलिज र वार्ता भएको ट्रान्सपोर्टमा निर्भर गर्छ। कागजात भएको र पालना गरिएकोबीचको यही खाडलमा प्रतिलिपि गरिएको सङ्ख्या गल्ती हुन्छ।
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
तेस्रो प्रश्न: लक्षण आकारमा निर्भर छ
आकारका समस्याको एउटा हस्ताक्षर हुन्छ: साना अनुरोध सफल हुन्छन्, ठूला अपलोड वा ठूला प्रतिक्रिया अड्किन्छन्, र त्यही सेवा अर्को पहुँच सञ्जालमा चल्छ। फिल्टरिङ, एपको पेलोड सीमा र अड्किएको सर्भरले पनि उस्तै गुनासो उत्पन्न गर्न सक्छ, त्यसैले असफल हुने एउटा कार्य सफल हुनेको छेउमा लेख्नुहोस्। एपले समय र आकार बताउँछ भने दुवै तिनका साथ लेख्नुहोस्। त्यो जोडी नभए पछिको हरेक परिवर्तन अनुमान हो।
त्यही परीक्षण Wi-Fi र मोबाइल सञ्जालमा गर्नुहोस्। सञ्जाललाई पछ्याउने असफलता मार्गतिर सङ्केत गर्छ; यन्त्रलाई पछ्याउने क्लाइन्ट वा प्रोफाइलतिर, र दुवैलाई फरक मालिक चाहिन्छ। दुवै चलनका लागि एउटै सेवा र एउटै खाता प्रयोग गर्नुहोस्, नत्र तुलनाले केही बताउँदैन।
Mac को विधि किन बारम्बार आउँछ
PPP आधारित डेस्कटप VPN का वर्षौंले इन्टरफेस आकार बदल्नुलाई वैध स्थानीय उपाय बनाए, र ती निर्देशन मोबाइल छलफलमा प्रतिलिपि भए। फोनमा शेल छैन, त्यस्तो इन्टरफेस नाम छैन, र पुनः जडानपछि स्थायित्व छैन। 2011 मा डेस्कटप समस्या समाधान गर्ने विधि त्यसलाई सत्य बनाउने अवस्थाभन्दा धेरै टाढा पुगी। छलफलले जे दाबी गरे पनि, मोबाइल क्लाइन्टले यसका लागि कुनै शेल आदेश स्वीकार गर्दैनन्।
प्रतिलिपि गरिएको मानलाई सेटिङ होइन, मार्गबारे परिकल्पना ठान्नुहोस्। सानो आकारले स्थानान्तरण चलायो र ठूलोले भरपर्दो रूपमा असफल भयो भने मार्गबारे तपाईंसँग प्रमाण छ; त्यसमा कार्य गर्न अनुमति पाएको घटक अझै खोज्नुपर्छ। त्यो खोज प्रायः गेटवे प्रोफाइल वा एप विक्रेतामा टुङ्गिन्छ, र फोनमा विरलै।
ट्रान्सपोर्टले उत्तर बदल्छ
सत्र IPsec नभई TLS मा चलिरहेको भए गेटवेमा TCP खण्डीकरण समायोजनले सहयोग गर्न सक्छ, किनकि यसले TCP प्रवाहका लागि घोषित खण्ड आकार पुनः लेख्छ। UDP ट्राफिकका लागि यसले केही गर्दैन, र त्यसमा मानिसले अपेक्षा गरेभन्दा बढी आधुनिक वेब पर्छ। परिवर्तन प्रस्ताव गर्नु अघि वार्ता भएको ट्रान्सपोर्ट जाँच्नुहोस्, र टिकटमा कुन ट्रान्सपोर्टमा असर पर्ने अपेक्षा छ लेख्नुहोस्।
मार्ग MTU पत्ता लगाउने काम यसका लागि छ कि छेउहरूले अनुमान होइन वास्तविक सीमा सिकून्। फिडब्याक रोक्ने र सानो आकार हार्ड-कोड गर्ने कामले चल्ने ठूलो स्थानान्तरणलाई हरेक जडानमा स्थायी, लुकेको लागतसँग साट्छ।
गेटवे टिमलाई के सोध्ने
तीन कुरा माग्नुहोस्: विशेषताको ठ्याक्कै नाम र त्यसको दायरा, तैनाथ क्लाइन्टले त्यसको पालना गर्छन् कि गर्दैनन्, र सत्रले कुन ट्रान्सपोर्टमा वार्ता गर्यो। एउटा समूह नीतिमा लागू गरिएको परिवर्तन परीक्षण गर्न सकिन्छ; विश्वव्यापी सम्पादन सकिँदैन, र यसले जोखिम कहिल्यै समस्या नबताएका प्रयोगकर्तामा सार्छ। कागजातको सन्दर्भ पनि माग्नुहोस्, किनकि विशेषताका नाम रिलिजबीच बदलिन्छन्।
त्यसपछि एउटा कुरा बदल्नुहोस् र मूल असफल कार्य पुनः परीक्षण गर्नुहोस्, स्पिड-टेस्ट डाउनलोड होइन। क्लाइन्ट संस्करण र पहुँच सञ्जालसहित अघि-पछिको अभिलेख राख्नुहोस्, ताकि अर्को प्रतिवेदन पुनः बहस होइन तुलना गर्न सकियोस्।
मूल आकारमै पनि कार्य असफल भइरहेको भए आकार कारण थिएन। त्यो निष्कर्ष पनि अभिलेख गर्नुहोस्, ताकि अर्को व्यक्तिले त्यही परिकल्पना फेरि नखोलोस्।