Android-ന്റെ ഒറ്റ VPN നിയമം ഹോസ്റ്റ് ചെയ്ത SSH സെർവറെ തടയുന്നില്ല

ഈ വിശ്വാസം ഒരു വസ്തുതയായി കണക്കാക്കുന്നത്ര സാധാരണമാണ്: Android ഒരു VPN മാത്രമേ അനുവദിക്കുന്നുള്ളൂ, അതിനാൽ ഫോണിൽ പ്രവർത്തിക്കുന്ന SSH സെർവറിന് ആ ടണലിലൂടെ പ്രവർത്തിക്കാനാവില്ല. ആദ്യ പകുതി ശരിയാണ്, നിഗമനം അതിൽ നിന്ന് വരുന്നില്ല. പ്ലാറ്റ്ഫോമിന്റെ പരിധി എത്ര ആപ്പുകൾക്ക് VPN സേവനത്തിന്റെ സ്ലോട്ട് പിടിക്കാം എന്നതിനെക്കുറിച്ചാണ്, എത്ര സോക്കറ്റുകൾ നിലനിൽക്കാം അല്ലെങ്കിൽ ആർക്ക് ഫോണിലേക്ക് കണക്ട് ചെയ്യാം എന്നതിനെക്കുറിച്ചല്ല. കേൾക്കുന്ന സോക്കറ്റുള്ള SSH ഡീമൺ സാധാരണ പോർട്ടുള്ള സാധാരണ ആപ്പാണ്, ടണൽ അതിന്റെ ട്രാഫിക് പോകാവുന്ന പാതകളിൽ ഒന്നു മാത്രം.

ഒറ്റ VPN നിയമം യഥാർത്ഥത്തിൽ എന്താണ് പരിമിതപ്പെടുത്തുന്നത്

VpnService ഒരു സ്ലോട്ട് മാത്രമുള്ള വിഭവമാണ്. ഒരു ആപ്പ് ടണൽ സ്ഥാപിക്കുമ്പോൾ അത് ഉപകരണത്തിന്റെ VPN ആകുന്നു, ടണൽ സ്ഥാപിക്കാൻ ശ്രമിക്കുന്ന രണ്ടാമത്തെ ആപ്പ് ആദ്യത്തേത് പോകുന്നതുവരെ നിരസിക്കപ്പെടുന്നു. അത് ടണലിന്റെ ഉടമസ്ഥതയെക്കുറിച്ചുള്ള നിയമമാണ്, രണ്ട് VPN ക്ലയന്റുകൾക്ക് ഒരേസമയം പ്രവർത്തിക്കാനാവാത്തതിന്റെ കാരണവും അതാണ്.

കേൾക്കുന്ന സോക്കറ്റുകളെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. SSH സെർവർ VpnService വിളിക്കുന്നില്ല, പാക്കറ്റുകൾ തടയുന്നില്ല, ആ സ്ലോട്ടിനായി മത്സരിക്കുന്നുമില്ല. അത് ഒരു പോർട്ട് ബൈൻഡ് ചെയ്ത് കണക്ഷനുകൾ സ്വീകരിക്കുന്നു, VPN ഒട്ടും ഇൻസ്റ്റാൾ ചെയ്യാതിരുന്നാലും അതേ കാര്യം ചെയ്യുമായിരുന്നു. അതിനാൽ ഈ കെട്ടുകഥ ടണൽ ദാതാക്കൾക്കുള്ള പരിധിയെ നെറ്റ്വർക്ക് കണക്ഷനുകൾക്കുള്ള പരിധിയുമായി കൂട്ടിക്കലർത്തുന്നു, രണ്ടിനും തമ്മിൽ ബന്ധമില്ല.

ലിസണർ ഒരു ലക്ഷ്യസ്ഥാനമാണ്, ടണലിന്റെ ഭാഗമല്ല

ടണൽ നിലവിലുള്ളപ്പോൾ ഫോണിന് അതിൽ ഒരു വിലാസമുണ്ട്, പിയർ ഉപകരണത്തിന് ആ വിലാസത്തിലേക്ക് ഒരു റൂട്ടുമുണ്ട്. എന്തെങ്കിലും മറുപടി നൽകുന്നുണ്ടോ എന്ന് ലിസണർ തീരുമാനിക്കുന്നു. loopback-ൽ ബൈൻഡ് ചെയ്ത ഡീമണിൽ ഫോണിൽ നിന്ന് മാത്രമേ എത്താനാവൂ; പഴയ ടണൽ വിലാസത്തിൽ ബൈൻഡ് ചെയ്ത ഡീമൺ വീണ്ടും കണക്ട് ചെയ്ത ശേഷവും ബൈൻഡിംഗ് നിലനിർത്തിയേക്കാം, എന്നാൽ അത് ബൈൻഡ് ചെയ്ത വിലാസം മാറിയിരിക്കും.

ബൈൻഡിംഗ് നിയമങ്ങൾ സാധാരണ SSH കോൺഫിഗറേഷനാണ്: കേൾക്കുന്ന വിലാസവും പോർട്ടും, ആർക്ക് ഓതന്റിക്കേഷൻ നടത്താം എന്നതും. Android-ൽ ആ ക്രമീകരണങ്ങൾ ആപ്പിന്റെ സ്വന്തം കോൺഫിഗറേഷനിലാണ്, ആപ്പിന്റെ പ്രോസസ് ഉടമയ്ക്ക് പ്രിവിലേജഡ് പോർട്ടുകൾ ഉപയോഗിക്കാൻ അനുമതി ഇല്ലായിരിക്കാം, അതിനാൽ root ആയി പോർട്ട് 22 ബൈൻഡ് ചെയ്യുന്ന ഡെസ്ക്ടോപ്പ് ശീലം മാറ്റമില്ലാതെ കൈമാറില്ല.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

പിന്നെ പാതയിൽ തന്നെയുള്ള അനുമതിയാണ്. പുറത്തേക്കുള്ള വെബ് ട്രാഫിക് സന്തോഷത്തോടെ വഹിക്കുന്ന ഉപഭോക്തൃ VPN തന്റെ ക്ലയന്റുകളിലേക്ക് അകത്തേക്കുള്ള കണക്ഷനുകൾ അനുവദിക്കേണ്ടതില്ല; പലതും അനുവദിക്കുന്നില്ല, കാരണം അത് ഒരു ഉപഭോക്താവിനെ മറ്റൊരാൾക്ക് വെളിപ്പെടുത്തും. പിയർക്ക് എവിടെ നിന്നും ഫോണിന്റെ ടണൽ വിലാസത്തിൽ എത്താനാവുന്നില്ലെങ്കിൽ, പ്രശ്നം സേവനത്തിന്റെ നയത്തിലാണ്, ഫോണിലല്ല.

മറുപടി പാതയാണ് സാധാരണയായി പൊട്ടുന്നിടം

പിയർ ഫോണിന്റെ ടണൽ വിലാസത്തിൽ എത്തി SYN വരുന്നു എന്ന് കരുതുക. ഇനി മറുപടി അതേ പാതയിലൂടെ പുറത്തുപോകണം, അത് ഫോണിനുള്ളിലെ റൂട്ടിംഗ് തീരുമാനമാണ്. മറുപടി ഡിഫോൾട്ട് നെറ്റ്വർക്ക് ആയതിനാൽ Wi-Fi വഴി പുറത്തുപോയാൽ, പിയർ ഒരിക്കലും പൂർത്തിയാകാത്ത ഒരു കണക്ഷൻ കാണുന്നു, അത് ഫയർവാളിനെപ്പോലെ തന്നെ തോന്നും.

Android ഇത് ഡെസ്ക്ടോപ്പിനെക്കാൾ സങ്കീർണ്ണമാക്കുന്നു, കാരണം ഡിഫോൾട്ട് നെറ്റ്വർക്ക് ഓരോ പ്രോസസിനും തിരഞ്ഞെടുക്കുന്നു, VPN ആപ്പിന്റെ നയത്തിന് അത് മാറ്റാനും കഴിയും. VPN ക്ലയന്റിന് അനുവദിച്ച ആപ്പുകളുടെ ഒരു പട്ടിക മാത്രമേ റൂട്ട് ചെയ്യാനാകൂ, അതിനാൽ ആ പട്ടികയ്ക്ക് പുറത്തുള്ള സെർവർ ആപ്പ് തന്റെ മറുപടികൾക്ക് ഭൗതിക നെറ്റ്വർക്ക് തുടർന്നും ഉപയോഗിക്കുന്നു, പിയർ അവ ടണലിലൂടെ പ്രതീക്ഷിക്കുമ്പോൾ.

ഒരു ആപ്പിന് തന്റെ സോക്കറ്റുകൾ ഒരു നിർദ്ദിഷ്ട നെറ്റ്വർക്കിലേക്ക് ബൈൻഡ് ചെയ്യാനും കഴിയും, അത് ഡിഫോൾട്ടിനെ മറികടക്കുന്നു. ഒരു സേവനം ഒരു വിലാസത്തിൽ നിന്ന് എത്താനാകും, മറ്റൊന്നിൽ നിന്ന് എത്താനാകില്ല എന്ന റിപ്പോർട്ട് വായിക്കുമ്പോൾ, സാധാരണയായി ഇതാണ് അതിന് പിന്നിലെ സംവിധാനം.

VPN ഒഴിവാക്കുന്നത് ഇൻബൗണ്ട് സേവനത്തെ നന്നാക്കുന്നില്ല

ജനപ്രിയ പരിഹാരം, SSH ആപ്പിനെ VPN-ൽ നിന്ന് ഒഴിവാക്കുന്നത് അതിന്റെ ട്രാഫിക് ഇനി റീഡയറക്‌ട് ചെയ്യപ്പെടാതിരിക്കാൻ, വിപരീത പ്രശ്നത്തിനുള്ള പരിഹാരമാണ്. പുറത്തേക്കുള്ള SSH ക്ലയന്റിന്റെ ട്രാൻസ്‌പോർട്ട് ടണൽ കാരണം വീണ്ടും വീണ്ടും പൊട്ടുമ്പോൾ ഇത് സഹായിക്കുന്നു. ഹോസ്റ്റ് ചെയ്ത സെർവറിന് ഇത് പിയർ ഉപയോഗിക്കുന്ന ടണലിൽ നിന്ന് മറുപടികൾ പുറത്തേക്ക് മാറ്റിയേക്കാം, അത് ഭാഗിക പരാജയത്തെ പൂർണ്ണ പരാജയമാക്കി മാറ്റുന്നു.

റൗട്ടറിൽ പൊതു പോർട്ട് തുറക്കുന്നതിനും ഇത് ബാധകമാണ്. ആവശ്യകത ഒരു അംഗീകൃത ഉപകരണം VPN വഴി ഫോണിൽ എത്തുക എന്നതാണെങ്കിൽ, SSH ഇന്റർനെറ്റിലേക്ക് തുറക്കുന്നത് മറ്റൊരു ഭീഷണി മാതൃകയാണ്, അറ്റകുറ്റപ്പണിയല്ല.

ആദ്യം സേവനത്തിന്റെ വിലാസം തീരുമാനിക്കുക: ഫോണിന്റെ LAN വിലാസം, അതിന്റെ ടണൽ വിലാസം, അല്ലെങ്കിൽ ബോധപൂർവം ഫോർവേഡ് ചെയ്ത എൻഡ്‌പോയിന്റ്. ഓരോന്നിനും അതിന്റേതായ എത്തിച്ചേരലും വെളിപ്പെടുത്തലും ഉള്ള കരാറുണ്ട്, അവ കൂട്ടിക്കലർത്തുന്നതാണ് ഒരു ചെറിയ ആക്സസ് പ്രശ്നത്തെ സ്ഥിരമായ ദ്വാരമാക്കുന്ന വഴി.

ഒരു സമയം ഒരു ദിശ മാത്രം രോഗനിർണയം ചെയ്യുക

കോൺഫിഗറേഷൻ മാറ്റുന്നതിന് മുമ്പ് നാല് വസ്തുതകൾ എഴുതുക: പിയർ കണക്ട് ചെയ്യുന്ന വിലാസം, ഫോണിലെ ലിസണറുടെ അവസ്ഥ, അത് കൈവശം വയ്ക്കുന്ന ആപ്പിന്റെയും ഉപയോക്താവിന്റെയും സന്ദർഭം, ഓരോ ദിശയിലും നിരീക്ഷിച്ച പാത. VPN SSH വിച്ഛേദിക്കുന്നു എന്ന് പറയുന്ന റിപ്പോർട്ടിൽ ഇവയൊന്നും ഉണ്ടാകില്ല, ക്ലയന്റ് ട്രാൻസ്‌പോർട്ട് പ്രശ്നത്തെ എത്തിച്ചേരാനാവാത്ത സെർവറിൽ നിന്ന് വേർതിരിക്കാനും അതിനാവില്ല.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

പോർട്ട് പരിശോധന ഫോണിൽ നിന്നല്ല, പിയറിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുക, SSH ക്ലയന്റിന്റെ വിശദമായ ഔട്ട്‌പുട്ട് വായിച്ച് അത് TCP ഹാൻഡ്‌ഷേക്കിന് മുമ്പോ ശേഷമോ പരാജയപ്പെടുന്നു എന്ന് നോക്കുക. ഒരിക്കലും കണക്ട് ചെയ്യാത്ത സോക്കറ്റും നിരസിക്കപ്പെടുന്ന ലോഗിനും വ്യത്യസ്ത ഘട്ടങ്ങളാണ്, ഉത്തരവാദികളും വ്യത്യസ്തരാണ്.

ഡീബഗ്ഗ് ചെയ്യുമ്പോൾ ഹോസ്റ്റ്-കീ പരിശോധനയും അക്കൗണ്ട് നിയന്ത്രണങ്ങളും അസ്പൃശ്യമായി സൂക്ഷിക്കുക. ലിസണറും അനുവദിച്ച ഉപയോക്താക്കളും പരിമിതപ്പെടുത്തുന്നതാണ് എത്താനാകുന്ന ഒരു സെർവറിനെ സ്വീകാര്യമാക്കുന്നത്; കണക്ഷൻ പ്രവർത്തിക്കാൻ അവ അയച്ചുവിടുന്നത് ഒരു പ്രശ്നത്തെ അതിലും മോശമായ ഒന്നുമായി മാറ്റുന്നു. OpenSSH സെർവർ റഫറൻസ് നിങ്ങളുടെ Android നിർവ്വഹണം അതേ കോൺഫിഗറേഷൻ പേരുകൾ പിന്തുടരുന്നുവെങ്കിൽ കേൾക്കൽ, ആക്സസ് നിയന്ത്രണങ്ങൾ ഉൾക്കൊള്ളുന്നു.