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 എന്ന് പറയുന്നുവെങ്കിൽ, പ്രോക്സി ഫീൽഡ് അതിൽ ഒന്നും മാറ്റിയിട്ടില്ല.
ഫീൽഡ് ശരിയായ ഉപകരണമാകുമ്പോൾ
പ്രോക്സി ടണലിന് മുന്നിൽ നിൽക്കുന്ന ഒരു യഥാർത്ഥ സന്ദർഭമുണ്ട്, പക്ഷേ അത് പ്രൊഫൈൽ ഫീൽഡല്ല, ക്ലയന്റ് സവിശേഷതയാണ്. HTTP CONNECT പ്രോക്സിയിലൂടെ കൊണ്ടുപോകുന്ന TCP കണക്ഷനുകൾക്കായി OpenVPN-ന്റെ മാനുവൽ --http-proxy രേഖപ്പെടുത്തുന്നു. ഇത് ഉപയോഗിക്കാൻ യോജിക്കുന്ന ക്ലയന്റ് ഓപ്ഷൻ, അങ്ങനെ എത്താവുന്ന ഗേറ്റ്‌വേ, ഉപയോഗത്തിലുള്ള പോർട്ടിലേക്ക് CONNECT അനുവദിക്കുന്ന പ്രോക്സി എന്നിവ വേണം.
നിങ്ങളുടെ ക്ലയന്റ് ആ ഓപ്ഷൻ നൽകുകയും നെറ്റ്‌വർക്ക് പോർട്ടിലേക്ക് CONNECT അനുവദിക്കുകയും ചെയ്താൽ അത് പ്രവർത്തിച്ചേക്കാം. ക്ലയന്റ് അത് നൽകുന്നില്ലെങ്കിൽ, സിസ്റ്റം പ്രോക്സി പൂരിപ്പിക്കുന്നത് ടണലിൽ ഒരു സ്വാധീനവും ചെലുത്തുന്നില്ല.
ഒന്നും മാറ്റാത്തപ്പോൾ
പ്രോക്സി ഫീൽഡ് പൂരിപ്പിച്ചതുകൊണ്ട് IKEv2 അല്ലെങ്കിൽ IPsec പ്രൊഫൈൽ HTTP ടണലാകുന്നില്ല. പ്രോക്സി ആശയമില്ലാത്ത കോൺഫിഗറേഷൻ ഫോർമാറ്റുള്ള WireGuard-ഉം അല്ല. ഗേറ്റ്‌വേ പോർട്ട് മാറ്റുന്നത് അതിന്റെ പ്രോട്ടോക്കോളും മാറ്റുന്നില്ല. സാധാരണ HTTPS-ന് ഉത്തരം നൽകുന്ന എൻഡ്‌പോയിന്റ് സ്വയമേവ VPN ലിസണർ അല്ല.
അതേ കെണി പഴയ iPad ഗൈഡുകളിൽ നിന്ന് PPTP കാലഘട്ടത്തിലെ പ്രൊഫൈലുകൾ പകർത്തുന്നവരെയും പിടിക്കുന്നു. ഓപ്ഷനുകൾ ഇന്റർഫേസിൽ ഇപ്പോഴുമുണ്ട്; അവയ്ക്ക് പിന്നിലെ സേവനം ഇനി ആ പ്രോട്ടോക്കോളിൽ സംസാരിക്കുന്നില്ല.
ഏത് പാളി ശരിയാക്കണമെന്ന് തീരുമാനിക്കൽ
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഏത് പാളി പരാജയപ്പെട്ടുവെന്ന് ചോദിക്കുക. ക്ലയന്റിന് സെഷൻ സ്ഥാപിക്കാനാകാത്തെങ്കിൽ പ്രശ്നം ട്രാൻസ്പോർട്ടിലാണ്, പ്രോക്സി ഫീൽഡ് അപ്രസക്തമാണ്. ടണൽ പ്രവർത്തിക്കുന്നുവെങ്കിലും ഒരു ആപ്പിന് അതിന്റെ സെർവറിൽ എത്താനാകുന്നില്ലെങ്കിൽ ആപ്ലിക്കേഷൻ പ്രോക്സി പരിശോധിക്കേണ്ടതാണ്. ടണൽ പ്രവർത്തിക്കുന്നുവെങ്കിലും എല്ലാ ആപ്പുകളും പരാജയപ്പെട്ടാൽ ടണലിനുള്ളിലെ റൂട്ടിംഗും DNS-ഉം സംശയിക്കപ്പെടുന്നു.
ആദ്യ സന്ദർഭത്തിന്, ഏത് അംഗീകൃത ബദൽ ട്രാൻസ്പോർട്ട് അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് പിന്തുണയ്ക്കുന്നുവെന്ന് ഓപ്പറേറ്ററോട് ചോദിക്കുക. TCP 443-ൽ OpenVPN ഉള്ളത് ചില നെറ്റ്‌വർക്കുകൾ അത് മാത്രം അനുവദിക്കുന്നതിനാലാണ്, കൂടാതെ സെർവർ അത് കേൾക്കണമെന്ന് ഇപ്പോഴും ആവശ്യമാണ്.
തടയപ്പെട്ട UDP പോർട്ടിനെ തൽകാല പരിഹാരത്തിന്റെ അനുമതിയായി കാണരുത്. ഹാൻഡ്‌ഷേക്ക് യോജിപ്പിക്കാൻ ഗേറ്റ്‌വേയുടെ സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ ഐഡന്റിറ്റി പരിശോധനകൾ ഓഫ് ചെയ്യാതെ അവ അക്ഷതമായി നിലനിർത്തുക.
രണ്ട് പാളികളും ഓരോന്നായി പരിശോധിക്കുക
ആദ്യം ടണൽ സ്ഥിരീകരിക്കുക: ക്ലയന്റിന്റെ സ്റ്റാറ്റസ് പേജിൽ സ്ഥാപിത സെഷനും പൂജ്യമല്ലാത്ത ബൈറ്റ് എണ്ണവും നോക്കുക. തുടർന്ന് പ്രോക്സി ക്രമീകരണം നേരിട്ട് വായിക്കുക, ഫലപ്രദമായ കോൺഫിഗറേഷനായി scutil --proxy അല്ലെങ്കിൽ സംഭരിച്ച മൂല്യത്തിനായി networksetup -getwebproxy Wi-Fi ഉപയോഗിച്ച്. തുടർന്ന് സിസ്റ്റം പ്രോക്സി മാനിക്കുന്ന ഒരു ആപ്പും അത് അവഗണിക്കുന്ന ഒരു ആപ്പും പരീക്ഷിക്കുക, കാരണം പല നേറ്റീവ് ആപ്പുകളും അത് അവഗണിക്കുന്നു.
മൂന്ന് ഫലങ്ങൾ, മൂന്ന് വ്യത്യസ്ത തിരുത്തലുകൾ.
രണ്ട് പാളികളും വിജയം റിപ്പോർട്ട് ചെയ്യുന്നുവെങ്കിലും ആപ്പ് പരാജയപ്പെടുന്നുവെങ്കിൽ, സ്പ്ലിറ്റ് ടണലിംഗ്, DNS, ആപ്പിന്റെ സ്വന്തം നെറ്റ്‌വർക്ക് ക്രമീകരണങ്ങൾ എന്നിവ നോക്കുക. അത് മൂന്നാം പാളിയാണ്, അതും പ്രോക്സി ഫീൽഡല്ല.