Android always-on VPN: എൻഡ്പോയിന്റ് നാമം ആദ്യം എങ്ങനെ പരിഹരിക്കപ്പെടുന്നു
ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് തന്നെ Android ട്രാഫിക് തടയുന്നു, എന്നിട്ടും ക്ലയന്റ് അതിന്റെ എൻഡ്പോയിന്റ് പരിഹരിക്കേണ്ടതുണ്ട്. ഇതാ ക്രമവും കുടുങ്ങുന്ന ഇടവും.
ഫോൺ റീബൂട്ട് ചെയ്യുന്നു, always-on സജീവമാണ്, «VPN ഇല്ലാതെ കണക്ഷനുകൾ തടയുക» ഓണാണ്, പക്ഷേ ടണൽ ഒരിക്കലും വരുന്നില്ല. ഒന്നും തെറ്റായി കോൺഫിഗർ ചെയ്തിട്ടില്ല: തടയൽ അതിന്റെ ജോലി ചെയ്യുന്നു, ക്ലയന്റ് സ്വയം എൻഡ്പോയിന്റിലേക്ക് എത്താൻ ശ്രമിക്കുന്നതും അതിന് വിധേയമാണ്. മറ്റെല്ലാ ആപ്പുകൾക്കും അനുവാദമില്ലാത്തപ്പോൾ നെറ്റ്വർക്കുമായി സംസാരിക്കാൻ അനുവാദമുള്ള ഒരു ക്ലയന്റാണ് ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് എൻഡ്പോയിന്റ് നാമം പരിഹരിക്കേണ്ടത്. ഏത് ഘടകമാണ് അത് ചെയ്യുന്നതെന്നും ഏത് ക്രമത്തിലെന്നും മനസ്സിലാക്കുന്നതാണ് ഈ രഹസ്യത്തെ കോൺഫിഗറേഷൻ ചോദ്യമാക്കി മാറ്റുന്നത്.
VPN ബിൽഡർ യഥാർത്ഥത്തിൽ ആവശ്യപ്പെടുന്നത്
Android VPN ആപ്പ് പ്ലാറ്റ്ഫോമിന് സെർവർ വിലാസം നൽകുന്നില്ല. അത് ഒരു ലോക്കൽ ഇന്റർഫേസ് നിർമ്മിക്കുന്നു: ടണലിനുള്ള വിലാസങ്ങളും റൂട്ടുകളും, അതിനുള്ളിൽ ആപ്പുകൾ ഉപയോഗിക്കേണ്ട റിസോൾവറുകളും, പിന്നീട് establish() ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്റർ തിരികെ നൽകുന്നു, അത് ആപ്പ് അസംസ്കൃത IP പാക്കറ്റുകളായി വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നു. റിമോട്ട് എൻഡ്പോയിന്റ് ആ ബിൽഡറിൽ ഒട്ടും പ്രത്യക്ഷപ്പെടുന്നില്ല.
ഇതാണ് പ്രധാന ഘടനാപരമായ വസ്തുത. പ്ലാറ്റ്ഫോം ഒരു tun ഇന്റർഫേസ് സൃഷ്ടിച്ച് അതിൽ പോളിസി നടപ്പാക്കുന്നു; ആപ്പ് ഉപയോക്തൃ സ്ഥലത്ത് ട്രാൻസ്പോർട്ട് നടപ്പാക്കുന്നു, അതായത് എൻഡ്പോയിന്റ് നാമം പരിഹരിക്കുന്നതും എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ തുറക്കുന്നതും ആപ്പ് തന്നെ ചെയ്യുന്നു. അതിനാൽ ഹോസ്റ്റ്നെയിം എൻഡ്പോയിന്റ് സാധ്യമാണ് — പ്ലാറ്റ്ഫോം നാമങ്ങളെ പിന്തുണയ്ക്കുന്നതുകൊണ്ടല്ല, പ്ലാറ്റ്ഫോം എൻഡ്പോയിന്റ് ഒരിക്കലും കാണാത്തതുകൊണ്ടാണ്.
ബിൽഡറിലെ ഒരു ഫീൽഡ് മാത്രം വിലാസങ്ങൾ സ്വീകരിക്കുന്നു: DNS സെർവറുകൾ. അവ സംഖ്യാത്മക റിസോൾവർ വിലാസങ്ങളായിരിക്കണം, സാധാരണയായി ഓപ്പറേറ്റർ ടണലിലൂടെ ചോദിക്കാൻ ആഗ്രഹിക്കുന്നവ. ആ ഫീൽഡ് ടണൽ വന്നതിന് ശേഷം ആപ്പുകൾ ക്വറികൾ എവിടേക്ക് അയക്കുന്നു എന്ന് വിവരിക്കുന്നു. ക്ലയന്റ് എങ്ങനെ എൻഡ്പോയിന്റ് കണ്ടെത്തുന്നു എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, ഈ രണ്ടിനെയും ഒരേ ക്രമീകരണമായി കാണുന്നതാണ് ആശയക്കുഴപ്പത്തിന്റെ തുടക്കം.
ഒന്നല്ല, രണ്ട് DNS ചോദ്യങ്ങൾ
ആദ്യ ചോദ്യം: ടണൽ വന്നതിന് ശേഷം ആപ്പുകൾ ക്വറികൾ എവിടേക്ക് അയക്കുന്നു? ഉത്തരം ടണലിനുള്ളിലെ റിസോൾവർ വിലാസമാണ്, tun ഇന്റർഫേസിലൂടെ എത്താവുന്നതും നിർമ്മാണപരമായി സംഖ്യാത്മകവുമാണ്.
രണ്ടാമത്തെ ചോദ്യം: ആ ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് ക്ലയന്റ് അതിന്റെ സ്വന്തം എൻഡ്പോയിന്റ് എങ്ങനെ കണ്ടെത്തുന്നു? ആ തിരച്ചിൽ ടണലിന് പുറത്ത്, അടിസ്ഥാന നെറ്റ്വർക്കിൽ, ക്ലയന്റിന്റെ പ്രോസസ്സിൽ നടക്കുന്നു. അതിന് ഒരു നാമം ഉപയോഗിക്കാം, VPN ഇല്ലാതെ ഉപകരണത്തിന് എത്താവുന്ന ഒരു റിസോൾവർ ഉപയോഗിക്കണം.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
മൂന്ന് ഘട്ടങ്ങൾ, മൂന്ന് വ്യത്യസ്ത ലക്ഷണങ്ങൾ. «കണക്ട് ചെയ്യാനാകുന്നില്ല» എന്ന ഒരൊറ്റ പിശക് സന്ദേശം അവയെ ഒന്നിച്ച് ചേർക്കുന്നു, അതുകൊണ്ടാണ് ആ ഫീൽഡ് വായിക്കുന്നതിന് മുമ്പ് തന്നെ സംഭവിക്കുന്ന ഒരു പ്രശ്നം പരിഹരിക്കാൻ ആളുകൾ DNS സെർവർ ഫീൽഡ് തിരുത്താൻ തുടങ്ങുന്നത്.
bootstrap എന്തുകൊണ്ട് കുടുങ്ങാം
always-on-ൽ തടയൽ സജീവമായാൽ VPN-നുള്ളിൽ ഇല്ലാത്ത ട്രാഫിക് ഉപേക്ഷിക്കപ്പെടും, VPN ഉള്ള ആപ്പിന്റെ ട്രാഫിക് ഉൾപ്പെടെ. പുറത്തുകടക്കാനുള്ള വഴി വ്യക്തമാണ്: ആപ്പ് ഒരു സോക്കറ്റിൽ protect() വിളിക്കുന്നു, അത് അതിനെ അടിസ്ഥാന നെറ്റ്വർക്കിലേക്ക് ബന്ധിപ്പിക്കുന്നു, അതിനാൽ അത് ടണലിനെ ഒഴിവാക്കി പുറത്തുപോകാൻ അനുവദിക്കപ്പെടുന്നു. ഓരോ VPN ക്ലയന്റും അതിന്റെ സ്വന്തം ട്രാൻസ്പോർട്ടിനായി ഇത് ചെയ്യണം, അല്ലാത്തപക്ഷം സെർവറിൽ എത്താനാകില്ല.
ഇപ്പോൾ എൻഡ്പോയിന്റ് നാമം അറിയുന്ന ഏക റിസോൾവർ തന്നെ ടണലിനുള്ളിൽ ഉള്ള ഒരു വിന്യാസം പരിഗണിക്കുക. നാമം പരിഹരിക്കാൻ ക്ലയന്റിന് ടണൽ വേണം, ടണൽ നിർമ്മിക്കാൻ നാമം വേണം. ഇത് യഥാർത്ഥ വൃത്താകൃതിയിലുള്ള ആശ്രിതത്വമാണ്, ഏത് ക്ലയന്റ് കോൺഫിഗറേഷനും ഇത് പരിഹരിക്കില്ല. ഇത് ഡിസൈൻ പിഴവാണ്, ബഗ്ഗല്ല.
സമയം അതേ ആശ്രിതത്വം മൃദുരൂപങ്ങളിൽ വെളിപ്പെടുത്തുന്നു. ബൂട്ട് സമയത്ത്, ആദ്യ അൺലോക്കിന് മുമ്പ്, ഉപകരണത്തിന് ഇപ്പോഴും ഉപയോഗയോഗ്യമായ നെറ്റ്വർക്ക് ഇല്ലായിരിക്കാം; captive portal-ൽ നെറ്റ്വർക്ക് ഉണ്ട്, പക്ഷേ പോർട്ടൽ ഒഴികെ എല്ലാം തടയുന്നു; Wi-Fi-ൽ നിന്ന് മൊബൈലിലേക്ക് മാറുമ്പോൾ സംരക്ഷിത സോക്കറ്റിന്റെ അടിസ്ഥാന നെറ്റ്വർക്ക് മാറുന്നു, ക്ലയന്റ് അത് ശ്രദ്ധിച്ച് വീണ്ടും പരിഹരിക്കണം. ഇവയോരോന്നും bootstrap സംഭവമാണ്, ഓരോന്നും രാത്രി 3 മണിക്ക് കണ്ടെത്തുന്നതിന് പകരം ബോധപൂർവം പരീക്ഷിക്കേണ്ടതാണ്.
ഉത്തരം ഉറപ്പിക്കുന്നത് എന്തുകൊണ്ട് പരിഹാരമല്ല
പ്രലോഭിപ്പിക്കുന്ന വഴിത്തിരിവ് എന്നത് നാമം ഒരിക്കൽ പരിഹരിച്ച് ലഭിച്ച വിലാസം ഒരു സംഖ്യാ ഫീൽഡിൽ ഒട്ടിക്കുകയോ ഇഷ്ടാനുസൃത ബിൽഡിൽ ഹാർഡ്കോഡ് ചെയ്യുകയോ ചെയ്യുന്നതാണ്. അത് പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു, നാമത്തെ ഒരു സ്നാപ്പ്ഷോട്ടാക്കി മാറ്റുന്നു. ഓപ്പറേറ്റർ എൻഡ്പോയിന്റ് നീക്കുമ്പോൾ — ഒരു മൈഗ്രേഷൻ, ഒരു anycast മാറ്റം, ഒരു പുതിയ പ്രാദേശിക വിലാസം — ക്ലയന്റ് പഴയതിലേക്ക് തുടർന്നും വിളിക്കുന്നു, UI-ൽ എവിടെയും കാരണം വിശദീകരിക്കുന്നില്ല.
DNS റെക്കോർഡുകൾക്ക് TTL ഉള്ളത് ഉത്തരങ്ങൾ മാറാവുന്നതുകൊണ്ടാണ്; കാഷിംഗ് ആ ആയുസ്സിന്റെ അടിസ്ഥാനത്തിലാണ് നിർവചിക്കുന്നത്, എന്നെന്നും അല്ല. ഒരു ഉത്തരം ഉറപ്പിക്കുന്നത് ഒരു നാമത്തെ വിലാസത്തേക്കാൾ മികച്ചതാക്കുന്ന സംവിധാനം ഉപേക്ഷിക്കുന്നു, അതേസമയം നാമം ഉപയോഗിച്ചതിന്റെ പ്രവർത്തനച്ചെലവ് നിലനിർത്തുന്നു.
ഉറപ്പിക്കൽ സാധാരണയായി രണ്ടാമത്തെ മോശം ശീലത്തോടൊപ്പം വരുന്നു: കണക്ഷൻ ഇപ്പോൾ വ്യത്യസ്തമായി പരാജയപ്പെടുന്നതിനാൽ ഐഡന്റിറ്റി പരിശോധന അയയ്ക്കുന്നത്. സെർവർ ഐഡന്റിറ്റി പരിശോധന bootstrap പ്രശ്നത്തിന്റെ ഭാഗമല്ല, അത് ദുർബലമാക്കുന്നത് DNS ബുദ്ധിമുട്ടിനെ പിടികൂടൽ അപകടവുമായി കൈമാറുന്നു.
റീബൂട്ടിനെ അതിജീവിക്കുന്ന രൂപകൽപ്പനകൾ
നിലനിൽക്കുന്ന ക്രമീകരണം ആകർഷകമല്ല. സംരക്ഷിത സോക്കറ്റുകൾ ശരിയായി നടപ്പാക്കുകയും എൻഡ്പോയിന്റ് അടിസ്ഥാന നെറ്റ്വർക്കിൽ പരിഹരിക്കുകയും ചെയ്യുന്ന ഒരു ക്ലയന്റ് ഉപയോഗിക്കുക, പൊതുവായി അല്ലെങ്കിൽ ടണലിന് മുമ്പ് എത്താവുന്ന റിസോൾവർ വഴി പരിഹരിക്കപ്പെടുന്ന എൻഡ്പോയിന്റ് നാമം നൽകുക. തടയൽ ഓണായി വയ്ക്കുക; DNS പ്രവർത്തിക്കാൻ അത് പൂർണ്ണമായി ഓഫ് ചെയ്യുന്നത് ആ വിന്യാസം നിലനിൽക്കാനുള്ള കാരണമായ സവിശേഷത നീക്കം ചെയ്യുന്നു.
എൻഡ്പോയിന്റ് സ്വകാര്യമായി നിലനിൽക്കേണ്ടിടത്ത്, പ്ലാറ്റ്ഫോമിന് ഉപയോഗിക്കാവുന്ന വ്യക്തമായ ഒരു bootstrap പാത നൽകുക — ടണൽ ഇല്ലാതെ എത്താവുന്ന റിസോൾവർ, അല്ലെങ്കിൽ ഓപ്പറേറ്റർ പരിപാലിക്കുന്ന ഒരു മാനേജ്മെന്റ് കണക്ഷൻ — ആ ഒഴിവാക്കൽ ഇടുങ്ങിയതായി നിർത്തുക, ഉപയോക്തൃ ടോഗിളിനല്ല, പോളിസിക്ക് ഉടമസ്ഥതയുള്ളതാക്കുക. Android VpnService ഡോക്യുമെന്റേഷൻ സംരക്ഷണത്തെയും ലൈഫ്സൈക്കിളിനെയും കുറിച്ച് പ്ലാറ്റ്ഫോം എന്ത് ഉറപ്പുനൽകുന്നു എന്നതിന്റെ റഫറൻസാണ്, കൂടാതെ VpnService.Builder റഫറൻസ് DNS ഫീൽഡ് സംഖ്യാത്മക വിലാസങ്ങൾ സ്വീകരിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുന്നു.
തുടർന്ന് റീബൂട്ടിന് ശേഷമുള്ള പുതിയ കണക്ഷനിൽ മൂന്ന് ഘട്ടങ്ങളും ക്രമത്തിൽ പരിശോധിക്കുക: എൻഡ്പോയിന്റ് നാമം പരിഹരിക്കുന്നു, ടണൽ സ്ഥാപിക്കപ്പെടുന്നു, പിയർ പ്രാമാണീകരിക്കുന്നു, സ്വകാര്യ നാമം ടണലിന്റെ റിസോൾവർ വഴി പരിഹരിക്കുന്നു. ആദ്യ ഘട്ടം പരാജയപ്പെട്ടാൽ പിന്നീടുള്ളത് ഒന്നും പ്രവർത്തിക്കില്ല, തിരുത്തൽ bootstrap പാതയിൽ ആണ് — ഒരിക്കലും റിസോൾവർ ഫീൽഡിൽ അല്ല.
- എൻഡ്പോയിന്റ് പരിഹാരം നടക്കുന്നത് ആപ്പിൽ, ടണലിന് പുറത്ത്, സംരക്ഷിത സോക്കറ്റിൽ ആണ്.
- ബിൽഡറിലെ DNS ഫീൽഡ് ടണലിനുള്ളിലെ ആപ്പുകൾക്കുള്ളതാണ്, ക്ലയന്റിന്റെ സ്വന്തം എൻഡ്പോയിന്റിനല്ല.
- ടണലിലൂടെ മാത്രം എത്താവുന്ന റിസോൾവർ ഒരു കുടുക്കാണ്, മന്ദഗതിയിലുള്ള തുടക്കമല്ല.
- റീബൂട്ടിന് ശേഷം എൻഡ്പോയിന്റ്, പ്രാമാണീകരണം, സ്വകാര്യ ലുക്കപ്പ് എന്നിവ വെവ്വേറെ പരീക്ഷിക്കുക.