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 കണ്ടെത്തൽ ഉള്ളത് അഗ്രങ്ങൾക്ക് ഊഹിക്കുന്നതിന് പകരം യഥാർത്ഥ പരിധി പഠിക്കാനാണ്. ഫീഡ്ബാക്ക് തടയുകയും ചെറിയ വലിപ്പം കടുപ്പിച്ച് കോഡ് ചെയ്യുകയും ചെയ്യുന്നത് പ്രവർത്തിക്കുന്ന വലിയ കൈമാറ്റത്തെ ഓരോ കണക്ഷനിലും സ്ഥിരവും മറഞ്ഞതുമായ ചെലവിന് പകരം മാറ്റുന്നു.
ഗേറ്റ്വേ ടീമിനോട് എന്ത് ചോദിക്കണം
മൂന്ന് കാര്യങ്ങൾ ആവശ്യപ്പെടുക: ആട്രിബ്യൂട്ടിന്റെ കൃത്യമായ പേരും അതിന്റെ പരിധിയും, വിന്യസിച്ച ക്ലയന്റുകൾ അത് പാലിക്കുന്നുണ്ടോ, സെഷൻ ഏത് ട്രാൻസ്പോർട്ട് ചർച്ച ചെയ്തു. ഒരു ഗ്രൂപ്പ് നയത്തിൽ പ്രയോഗിച്ച മാറ്റം പരിശോധിക്കാനാകും; ആഗോള എഡിറ്റിംഗ് സാധ്യമല്ല, അത് പ്രശ്നം റിപ്പോർട്ട് ചെയ്യാത്ത ഉപയോക്താക്കളിലേക്ക് അപകടം മാറ്റുന്നു. ഡോക്യുമെന്റ് റഫറൻസും ആവശ്യപ്പെടുക, കാരണം ആട്രിബ്യൂട്ട് പേരുകൾ റിലീസുകൾക്കിടയിൽ മാറുന്നു.
പിന്നീട് ഒരു കാര്യം മാറ്റി യഥാർത്ഥ പരാജയപ്പെട്ട പ്രവർത്തനം വീണ്ടും പരിശോധിക്കുക, സ്പീഡ് ടെസ്റ്റ് ഡൗൺലോഡല്ല. ക്ലയന്റ് പതിപ്പും ആക്സസ് നെറ്റ്വർക്കും സഹിതം മുൻപും ശേഷവുമുള്ള രേഖ സൂക്ഷിക്കുക, അടുത്ത റിപ്പോർട്ട് വീണ്ടും ചർച്ച ചെയ്യുന്നതിന് പകരം താരതമ്യം ചെയ്യാനാകും.
യഥാർത്ഥ വലിപ്പത്തിൽ പ്രവർത്തനം ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ വലിപ്പമായിരുന്നില്ല കാരണം. ആ നിഗമനവും രേഖപ്പെടുത്തുക, അടുത്ത വ്യക്തി അതേ സിദ്ധാന്തം വീണ്ടും തുറക്കാതിരിക്കാൻ.