TAP അല്ലെങ്കിൽ TUN? Android OpenVPN ക്ലയന്റുകളും ബ്രിഡ്ജ് ചെയ്ത സർവറുകളും
TAP ഈതർനെറ്റ് ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു, TUN IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു, Android ആപ്പിന് രണ്ടാമത്തെ തരം മാത്രം ലഭിക്കുന്നു. രണ്ടും താരതമ്യം ചെയ്ത്, പിന്നീട് സർവർ ഭാഗം ശരിയാക്കുക.
ലാപ്‍ടോപ്പിൽ പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ ഫോണിൽ പരാജയപ്പെടുന്നു. വ്യക്തമായ നടപടി ക്ലയന്റ് കോൺഫിഗിൽ ഒരു വാക്ക് മാറ്റുന്നതാണ്. ആ വാക്ക് സഹായിക്കില്ല, കാരണം രണ്ട് അറ്റങ്ങളും ഒരേ തരം ട്രാഫിക്കിനെക്കുറിച്ചല്ല സംസാരിക്കുന്നത്.
TAP ഈതർനെറ്റ് ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു. TUN IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു. Android VPN ആപ്പിന് ഒരു IP ഇന്റർഫേസ് നൽകുന്നു, അത് രണ്ട് ക്രമീകരണങ്ങളിൽ ഒന്നിനെ സാധ്യമാക്കുകയും മറ്റേതിനെ അല്ലാതാക്കുകയും ചെയ്യുന്നു, കോൺഫിഗ് എന്ത് പറഞ്ഞാലും.
താരതമ്യം ചെറുതാണ്, പക്ഷേ ഇത് ഫോണിൽ തന്നെ ശരിയാക്കാമോ അതോ സേവനം മാറ്റണോ എന്ന് അത് തീരുമാനിക്കുന്നു.
വ്യത്യസ്ത പേലോഡുകളുള്ള രണ്ട് തരം ടണൽ
TAP ഇന്റർഫേസ് ഈതർനെറ്റ് അഡാപ്റ്റർ പോലെ പ്രവർത്തിക്കുന്നു. അത് ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു, അതായത് ARP, ബ്രോഡ്കാസ്റ്റ്, IP-ക്ക് താഴെ LAN കൊണ്ടുപോകുന്നതെല്ലാം. ഇതാണ് ബ്രിഡ്ജിംഗ് സാധ്യമാക്കുന്നത്: ടണൽ ഒരു ബ്രോഡ്കാസ്റ്റ് ഡൊമെയിൻ വിപുലീകരിക്കുന്നു, ക്ലയന്റുകൾ സ്വിച്ചിൽ ഘടിപ്പിച്ചതുപോലെ പ്രവർത്തിക്കുന്നു.
TUN ഇന്റർഫേസ് അതിന് വിലാസം നൽകിയ IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു. ചർച്ച ചെയ്യാൻ ഒരു ലിങ്ക് ലെയറും ഇല്ല, ARP ഇല്ല, ബ്രോഡ്കാസ്റ്റ് ഇല്ല. ടണലിൽ എന്ത് പ്രവേശിക്കുന്നു എന്ന് റൂട്ടിംഗ് തീരുമാനിക്കുന്നു, സർവർ ഭാഗത്തെ കോൺഫിഗ് ബ്രിഡ്ജിന് പകരം ഒരു സബ്നെറ്റ് ഉപയോഗിക്കുന്നു.
രണ്ട് അറ്റങ്ങളും ഇവയിൽ ഏതാണ് ചെയ്യുന്നതെന്ന് യോജിക്കണം. ഒരു വശത്ത് dev tap എന്നത് dev tun ആക്കി മാറ്റുന്നത് സേവനത്തെ പരിവർത്തനം ചെയ്യുന്നില്ല; റൂട്ട് ചെയ്ത ടണൽ പ്രതീക്ഷിക്കുന്ന ക്ലയന്റും ഇപ്പോഴും ഫ്രെയിമുകൾ അയക്കുന്ന സർവറും ഉണ്ടാകുന്നു, ഉപയോഗപ്രദമായ ഒന്നും കടന്നുപോകാതെ തന്നെ ഹാൻഡ്ഷേക്ക് വിജയിച്ചേക്കാം.
Android ആപ്പിന് യഥാർത്ഥത്തിൽ നൽകുന്നത്
പ്ലാറ്റ്ഫോമിന്റെ VpnService API ഒരു ആപ്പിന് IP പാക്കറ്റുകൾക്കായി ഒരു വിർച്വൽ ഇന്റർഫേസ് നൽകുന്നു, വിലാസങ്ങൾ, റൂട്ടുകൾ, MTU എന്നിവ ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്തത്. ആ API-യിൽ ഒരു ഈതർനെറ്റ് അഡാപ്റ്ററും ഇല്ല, ആപ്പിന് ഒന്ന് സൃഷ്ടിക്കാനുള്ള വഴിയുമില്ല.
അതുകൊണ്ടാണ് OpenVPN Connect Android-ൽ TAP ബ്രിഡ്ജിംഗിന് പകരം റൂട്ട് ചെയ്ത TUN കണക്ഷനുകൾക്കുള്ള പിന്തുണ രേഖപ്പെടുത്തുന്നത്. Android FAQ ഈ അതിർത്തിയെക്കുറിച്ചുള്ള ക്ലയന്റ് ഭാഗത്തെ പ്രസ്താവനയാണ്, അത് പ്ലാറ്റ്ഫോം API-യുമായി യോജിക്കുന്നു.
റൂട്ട് നെറ്റ്വർക്കിംഗ് ടൂളുകൾ, ഇഷ്ടാനുസൃത ഫേംവെയർ അല്ലെങ്കിൽ വ്യക്തമായ ഒരു വിവർത്തന പാളി നടപ്പിലാക്കുന്ന ഉൽപ്പന്നം എന്നിവ മറ്റ് ക്രമീകരണങ്ങളാണ്. സാധാരണ സാഹചര്യം ആസൂത്രണം ചെയ്യേണ്ടത് ഇതാണ്: നിങ്ങളുടെ ഫയൽ ഇമ്പോർട്ട് ചെയ്ത് സാധാരണ ഉപയോക്താവായി പ്രവർത്തിക്കാൻ കഴിയുന്ന ആപ്പ്, ഒരു IP ഇന്റർഫേസും അതിന് താഴെ ഒന്നുമില്ലാതെ.
എന്നിട്ടും ശ്രമിക്കുമ്പോൾ എങ്ങനെയിരിക്കും
കണക്ഷൻ സാധാരണയായി സ്ഥാപിക്കപ്പെടുന്നു. അതാണ് പരാജയത്തെ ആശയക്കുഴപ്പമാക്കുന്നത്: ക്ലയന്റ് കണക്ട് ചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്നു, സർവർ ലോഗ് ഒരു പിയർ കാണിക്കുന്നു, ഒരു ആപ്ലിക്കേഷനും പ്രവർത്തിക്കുന്നില്ല.
ഫോണിന് നൽകിയ വിലാസത്തിലേക്ക് അയച്ച ട്രാഫിക് എത്തുന്നില്ല, കാരണം സർവർ ഫ്രെയിമുകൾ ഫോണിന് ഒരിക്കലും ഇല്ലാതിരുന്ന ഒരു MAC വിലാസത്തിലേക്ക് ബ്രിഡ്ജ് ചെയ്യുന്നു. ബ്രോഡ്കാസ്റ്റിനെ ആശ്രയിക്കുന്ന കണ്ടെത്തൽ ശൂന്യമായി തുടരുന്നു. LAN ബ്രിഡ്ജിലൂടെ DHCP-യെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ഫോണിന് ആ വഴി ലീസ് ലഭിക്കില്ല, ബ്രിഡ്ജ് ചെയ്ത സബ്നെറ്റിൽ കൈകൊണ്ട് നൽകിയ വിലാസവും ഇല്ലാത്ത ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നില്ല.
ചില ക്ലയന്റുകൾ നേരത്തെ പരാജയപ്പെടുന്നു, പ്രൊഫൈൽ ഇമ്പോർട്ടിൽ, നടപ്പിലാക്കാൻ കഴിയാത്ത ഒരു ഉപകരണ തരം കാണുമ്പോൾ. രണ്ട് സ്വഭാവങ്ങളും ഒരേ കാര്യം അർത്ഥമാക്കുന്നു, റൂട്ടുകൾ ചേർക്കുകയോ DNS മാറ്റുകയോ ടണലിന്റെ വിലാസ ശ്രേണി വിശാലമാക്കുകയോ ചെയ്ത് രണ്ടും ശരിയാകുന്നില്ല.
സർവർ ഭാഗം എന്ത് മാറ്റണം
തിരുത്തൽ VPN സേവനം നടത്തുന്നവരുടേതാണ്, അത് സാധാരണയായി മാറ്റം വരുത്തലല്ല, കൂട്ടിച്ചേർക്കലാണ്. റൂട്ട് ചെയ്ത ഉപകരണം, സ്വന്തം ക്ലയന്റ് സബ്നെറ്റ്, വിലാസങ്ങൾ നൽകി ഫോണുകൾക്ക് ആവശ്യമായ റൂട്ടുകൾ അയക്കുന്ന സർവർ ഭാഗ കോൺഫിഗ് എന്നിവയുള്ള രണ്ടാമത്തെ OpenVPN ഇൻസ്റ്റൻസ് പ്രവർത്തിപ്പിക്കുക. നിലവിലുള്ള ബ്രിഡ്ജ് ചെയ്ത ഇൻസ്റ്റൻസ് ഈതർനെറ്റ് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഉപകരണങ്ങൾക്ക് സേവനം തുടരുന്നു.
രണ്ട് വിശദാംശങ്ങൾ ഇതിനെ പ്രായോഗികമായി പ്രവർത്തിപ്പിക്കുന്നു. പുതിയ ക്ലയന്റ് സബ്നെറ്റിനായി LAN-ന് VPN ഹോസ്റ്റിലേക്ക് ചൂണ്ടുന്ന ഒരു റിട്ടേൺ റൂട്ട് ആവശ്യമാണ്, അല്ലെങ്കിൽ മറുപടികൾ ഒരിക്കലും തിരികെ വരില്ല. ടണൽ ഹോസ്റ്റിലെ ഫയർവാൾ ടണൽ ഇന്റർഫേസും LAN-ഉം തമ്മിൽ ഫോർവേഡ് ചെയ്യണം, ഹോസ്റ്റിൽ നിന്ന് തന്നെയുള്ള ഒരു പരിശോധന വിജയിക്കുമ്പോൾ ഏറ്റവും കൂടുതൽ വിട്ടുപോകുന്ന ഘട്ടം ഇതാണ്.
ഓപ്പറേറ്റർക്ക് ഒരു സേവനം ചേർക്കാൻ കഴിയില്ലെങ്കിൽ, ബ്രിഡ്ജിൽ ചേരാൻ കഴിയുന്ന ഒരു ഉപകരണമാണ് പകരം, അതായത് ഫോണിന് വേണ്ടി പ്രവർത്തിക്കുന്ന ഒരു ലാപ്‍ടോപ്പ് അല്ലെങ്കിൽ റൂട്ടർ. അത് സ്വന്തം മാനേജ്മെന്റ് ചെലവുള്ള ഒരു വഴിത്തിരിവാണ്, Android കോൺഫിഗ് അല്ല.
ടണലിൽ നിന്നല്ല, ആപ്ലിക്കേഷനിൽ നിന്ന് തീരുമാനിക്കുക
ഫോൺ യഥാർത്ഥത്തിൽ എന്തിലേക്ക് എത്തണമെന്ന് ചോദിക്കുക, എന്നിട്ട് അത് മാപ്പ് ചെയ്യുക. പേരോ വിലാസമോ ഉപയോഗിച്ച് എത്തുന്ന ഫയൽ ഷെയറിംഗോ ഇന്ട്രാനെറ്റ് സൈറ്റോ IP ആവശ്യകതയാണ്, DNS പേര് പരിഹരിച്ച് റൂട്ട് നിലനിൽക്കുമ്പോൾ റൂട്ട് ചെയ്ത ടണൽ അത് നിറവേറ്റുന്നു. പ്രാദേശിക ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ ബ്രൗസ് ചെയ്യുന്ന കണ്ടെത്തൽ ഉപകരണം IP ആവശ്യകതയല്ല, എത്ര റൂട്ടിംഗ് നൽകിയാലും അത് നിറയ്ക്കില്ല.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
ആ പട്ടിക അയക്കേണ്ട അഭ്യർത്ഥന കൂടിയാണ്. ആപ്ലിക്കേഷൻ, അത് ഉപയോഗിക്കുന്ന വിലാസം അല്ലെങ്കിൽ പേര്, കണ്ടെത്തലിനെ ആശ്രയിക്കുന്നുണ്ടോ എന്നിവ പറയുക. ഓപ്പറേറ്റർക്ക് ആ വിവരണത്തിന്റെ അടിസ്ഥാനത്തിൽ പ്രവർത്തിക്കാം, കണക്ട് ചെയ്യാത്ത ഒരു ഫോണിനെക്കുറിച്ച് ആർക്കും അത് ചെയ്യാനാവില്ല.
അവസാനമായി, ഓരോ ക്ലയന്റിനെയും LAN അഡാപ്റ്റർ അനുകരിക്കാൻ നിർബന്ധിക്കുന്നതിന് പകരം ആവശ്യമുള്ള ഉപകരണങ്ങൾക്കായി TAP സേവനം നിലനിർത്തുക. വ്യക്തമായ ലക്ഷ്യങ്ങളുള്ള രണ്ട് സേവനങ്ങളെ പിന്തുണയ്ക്കുന്നത് എല്ലാവർക്കും പകുതി പ്രവർത്തിക്കുന്ന ഒന്നിനെക്കാൾ എളുപ്പമാണ്.