Android VpnService അനുവദനീയ പട്ടിക: അനുവദിച്ച പേജുകൾ ഇപ്പോഴും തങ്ങിനിൽക്കുന്നത് എന്തുകൊണ്ട്

നിങ്ങളുടെ അനുവദനീയ പട്ടിക കൂടുതലും ശരിയാണ്. DNS ഉത്തരം, റൂട്ട് പട്ടിക, റെസോൾവർ സോക്കറ്റ് അല്ലെങ്കിൽ MTU കാരണം പേജുകൾ തങ്ങിനിൽക്കുന്നു. പരിശോധനയുടെ ക്രമം ഇതാണ്.

നിങ്ങൾ ഒരു ഡൊമെയ്ൻ അനുവദനീയ പട്ടികയിൽ ചേർത്തു, ക്വറി നിങ്ങളുടെ ആപ്പിലെത്തുന്നു, മാച്ചർ അനുവദിച്ചു എന്ന് തിരികെ നൽകുന്നു, എന്നിട്ടും പേജ് ഒരിക്കലും ലോഡ് ആകുന്നില്ല. ആ ഘട്ടത്തിൽ മിക്കവരും മാച്ചർ വീണ്ടും എഴുതാനും വൈൽഡ്കാർഡ് താരതമ്യങ്ങൾ ചേർക്കാനും തുടങ്ങുന്നു. എന്റെ അനുഭവത്തിൽ മാച്ചർ സാധാരണ ശരിയാണ്, പരാജയം ഒരു പാളി താഴെയാണ്: നിങ്ങൾ നിർമ്മിച്ച DNS ഉത്തരത്തിൽ, നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടിൽ, അല്ലെങ്കിൽ ക്വറി കൈമാറാൻ ഉപയോഗിച്ച സോക്കറ്റിൽ. പട്ടിക എളുപ്പമുള്ള ഭാഗമാണ്; പാക്കറ്റ് പാതയാണ് അനുവദനീയ പട്ടികകൾ തകരുന്ന സ്ഥലം.

മാച്ചർ അപൂർവമായി മാത്രമേ കുറ്റക്കാരനാകൂ

ആദ്യം വേർതിരിക്കേണ്ടത് തടഞ്ഞതും തകർന്നതും ആണ്. തടഞ്ഞ പേര് വേഗത്തിൽ, ദൃശ്യമായി പരാജയപ്പെടണം, കാരണം പേര് നിലവിലില്ലെന്ന ഉത്തരം ബ്രൗസറിന് ലഭിച്ചാൽ അത് നിലയ്ക്കും. തകർന്ന പേര് തങ്ങിനിൽക്കും, IPv6 വഴി വീണ്ടും ശ്രമിക്കും, മറ്റൊരു ഗതാഗതത്തിലേക്ക് വീഴും, നിങ്ങൾക്ക് കറങ്ങുന്ന സൂചകം മാത്രം ബാക്കിയാകും. കറങ്ങുന്ന സൂചകം കണ്ടാൽ, നിങ്ങളുടെ അനുവദനീയ പട്ടിക ക്ലയന്റിന് ഒന്നും ചെയ്യാനാകാത്ത എന്തോ ഉത്തരം നൽകുകയാണ്.

ശൂന്യമായ A റെക്കോർഡ് പതിവ് തെറ്റാണ്. പൂജ്യം ഉത്തരങ്ങളോടെ NOERROR തിരികെ നൽകുന്നത് സാധുവായ ഉത്തരം പോലെ തോന്നും, അതിനാൽ stub റെസോൾവർ അത് സ്വീകരിക്കും, ബ്രൗസർ വീണ്ടും ശ്രമിക്കും, AAAA പരീക്ഷിക്കും, മറ്റൊരു റെസോൾവർ പരീക്ഷിക്കും, വളരെ വൈകി കീഴടങ്ങും. ചോദ്യ വിഭാഗം ആവർത്തിച്ച്, ട്രാൻസാക്ഷൻ ID പകർത്തി നൽകുന്ന ഉത്തര കോഡ് 3, അതായത് NXDOMAIN, സംഭാഷണം ഉടനെ അവസാനിപ്പിക്കും. ബോധപൂർവം നിഷേധിക്കുന്ന ഓരോ പേരിനും അത് ഉപയോഗിക്കുക.

IPv6-ഉം ഡിഫോൾട്ടിന് പകരം അതേ തീരുമാനത്തിന് അർഹമാണ്. A-ക്ക് NXDOMAIN ഉത്തരം നൽകി AAAA കടത്തിവിട്ടാൽ, ക്ലയന്റിന് IPv6 വഴി തടഞ്ഞ പേരിൽ എത്താനാകും, ഫിൽട്ടർ ചോരും. ചില നിർവ്വഹണങ്ങൾ തടഞ്ഞ AAAA ക്വറികൾക്ക് loopback വിലാസം നൽകി ബന്ധം ബദലിലേക്ക് പോകാതെ ഉടനെ പരാജയപ്പെടുത്തുന്നു. ഒരു നയം തിരഞ്ഞെടുത്ത് രണ്ട് റെക്കോർഡ് തരങ്ങൾക്കും പ്രയോഗിക്കുക, രണ്ടും ലോഗ് ചെയ്യുക.

എല്ലാം പിടിക്കുന്ന റൂട്ട് എല്ലാത്തിനും ഉടമയാണ്

DNS മാത്രമുള്ള രൂപകൽപ്പന ഒരിക്കലും addRoute("0.0.0.0", 0) ചേർക്കുന്നില്ല, അതിനാൽ TUN ഇന്റർഫേസിലേക്ക് ക്വറികൾ മാത്രം പ്രവേശിക്കുന്നു, ബാക്കിയെല്ലാം അടിസ്ഥാന നെറ്റ്വർക്ക് തുടർന്നും ഉപയോഗിക്കുന്നു. അതാണ് സുരക്ഷിത രൂപം, ചില അനുവദനീയ പട്ടികകൾ Wi-Fi-ൽ പ്രവർത്തിക്കുന്നതായും മൊബൈൽ നെറ്റ്വർക്കിൽ പരാജയപ്പെടുന്നതായും തോന്നുന്നതിന്റെ കാരണവും അതാണ്.

ഡിഫോൾട്ട് റൂട്ട് നിലവിലുള്ള നിമിഷം മുതൽ ഓരോ ഫ്ലോയും നിങ്ങളുടേതാണ്. ഇന്റർഫേസിൽ എത്തി കൈമാറപ്പെടാത്തതോ ഉത്തരം ലഭിക്കാത്തതോ ആയ TCP പാക്കറ്റ് ക്ലയന്റിന്റെ സമയം തീരുന്നതുവരെ ക്യൂവിൽ ഇരിക്കും, ഒന്നും പരാജയപ്പെടാത്തതിനാൽ ലോഗ് ചെയ്യാൻ പിശകുമില്ല. ഒരാൾ ഒരു ഉച്ചയ്ക്ക് തകർന്ന അനുവദനീയ പട്ടികയിൽ ചെലവിടുന്നത് ഞാൻ കണ്ടു, അത് യഥാർത്ഥത്തിൽ പോർട്ട് 443-നുള്ള കാണാത്ത ഫോർവാർഡർ ആയിരുന്നു. നിങ്ങൾ ഉപേക്ഷിക്കാൻ തീരുമാനിക്കുന്ന ഓരോ പാക്കറ്റിന്റെയും പ്രോട്ടോക്കോളും ലക്ഷ്യവും ലോഗ് ചെയ്യുക.

റെസോൾവർ സോക്കറ്റ് ടണലിൽ നിന്ന് പുറത്തുപോകണം

കൈമാറ്റമാണ് അടുത്ത കെണിയുടെ സ്ഥലം. കാരിയർ റെസോൾവറുകൾ പലപ്പോഴും ടണലിന് എത്താനാകാത്ത സ്വകാര്യ വിലാസത്തിലാണ്, അതിനാൽ നിങ്ങൾ കൈമാറുന്ന ക്വറി എങ്ങും പോകുന്നില്ല, ആപ്പ് വായനാ സമയപരിധി കഴിഞ്ഞതായി റിപ്പോർട്ട് ചെയ്യുന്നു. അനുവദിച്ച ക്വറികൾ എത്താനാകുമെന്ന് നിങ്ങൾക്ക് അറിയാവുന്ന റെസോൾവറിലേക്ക് അയക്കുക, ആ സോക്കറ്റ് ആദ്യം VpnService.protect()-ന് നൽകുക. സംരക്ഷിക്കപ്പെടാത്ത സോക്കറ്റ് ക്വറി നിങ്ങളുടെ സ്വന്തം ടണലിലേക്ക് തിരികെ അയക്കുന്നു, അവിടെ അത് വീണ്ടും ആപ്പിലെത്തി സമയപരിധി പ്രവർത്തിക്കുന്നതുവരെ കറങ്ങുന്നു.

പരാജയം നെറ്റ്വർക്ക് തകരാറിനോട് സമാനമായി തോന്നുന്നു, അതുകൊണ്ടാണ് ബഗ് റിപ്പോർട്ടുകളിൽ ഇത്രയും കാലം നിലനിൽക്കുന്നത്. അയച്ച ക്വറികൾക്കും ലഭിച്ച ഉത്തരങ്ങൾക്കും കൗണ്ടറുകൾ സൂക്ഷിക്കുക: ആദ്യ സംഖ്യ ഉയരുകയും രണ്ടാമത്തേത് പൂജ്യത്തിൽ നിൽക്കുകയും ചെയ്താൽ, നിങ്ങൾ പട്ടികയെയല്ല, സോക്കറ്റിനെയാണ് നോക്കുന്നത്.

വലിപ്പവും ചെക്ക്സവും സന്ദേശമില്ലാതെ പരാജയപ്പെടുന്നു

നിശബ്ദ വിടൽ വലിപ്പത്തിൽ നിന്നും ഉണ്ടാകാം. വലിയ ഉത്തര കൂട്ടമുള്ള DNS ഉത്തരം, അല്ലെങ്കിൽ വിശാലമായ ഓപ്ഷനുകളുള്ള TCP ഹാൻഡ്ഷേക്ക്, നിങ്ങൾ വ്യക്തമായി സജ്ജീകരിക്കാത്ത പാത MTU കവിയാം; ശകലം മുകളിലേക്ക് അപ്രത്യക്ഷമാകുന്നു, ക്ലയന്റ് ഒന്നുകിൽ ചെറുതായി വീണ്ടും ശ്രമിക്കും അല്ലെങ്കിൽ ശ്രമം നിർത്തും. ഇന്റർഫേസ് MTU 1280-ൽ സജ്ജീകരിക്കുന്നത് മിക്ക മൊബൈൽ പാതകളിലും നിലനിൽക്കുന്ന യാഥാസ്ഥിതിക തിരഞ്ഞെടുപ്പാണ്, ആരും അളക്കാത്ത ഡിഫോൾട്ട് പാരമ്പര്യമായി സ്വീകരിക്കുന്നതിനേക്കാൾ വ്യക്തമായിരിക്കുന്നത് നല്ലതാണ്.

നിങ്ങൾ തന്നെ പാക്കറ്റുകൾ നിർമ്മിക്കുന്നുവെങ്കിൽ, ചെക്ക്സം അടുത്ത നിശബ്ദ കൊലയാളിയാണ്. UDP ദൈർഘ്യമോ പ്രോട്ടോക്കോൾ ഫീൽഡോ ഒഴിവാക്കുന്ന സ്യൂഡോ തലക്കെട്ടിൽ കണക്കാക്കുന്ന UDP ചെക്ക്സം, നിങ്ങളുടെ ഭാഗത്ത് ശരിയായി കാണപ്പെടുന്നതും സ്വീകർത്താവ് അടയാളമില്ലാതെ വലിച്ചെറിയുന്നതുമായ പാക്കറ്റ് ഉണ്ടാക്കുന്നു. നിങ്ങളുടെ സ്യൂഡോ തലക്കെട്ട് സ്പെസിഫിക്കേഷനുമായി ഫീൽഡ് തോറും താരതമ്യം ചെയ്യുക, ഡീബഗ് ചെയ്യുമ്പോൾ ഒരു പരിചിത ഫ്ലോയുടെ കണക്കാക്കിയ ചെക്ക്സം പ്രിന്റ് ചെയ്യുക.

VpnService നിങ്ങൾക്കുവേണ്ടി ചെയ്യാത്തത്

അവയ്ക്ക് ചുറ്റും രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് പരിധികൾ അറിയേണ്ടതാണ്. Wi-Fi-ക്ക് പുറത്ത് സിസ്റ്റം-വ്യാപക പ്രോക്സിയോ PAC ഫയലോ ഇൻസ്റ്റാൾ ചെയ്യാൻ സാധാരണ ആപ്പിന് കഴിയില്ല, ആ ഭാഗം മാറിയിട്ടില്ല. ഓരോ ആപ്പിനുമുള്ള പാത മാറി: API 29-ന് മുമ്പ് VpnService.Builder-ക്ക് പ്രോക്സി ഒട്ടും വഹിക്കാനാകുമായിരുന്നില്ല, API 29 മുതൽ setHttpProxy(ProxyInfo.buildPacProxy(uri)) VPN നെറ്റ്വർക്കിനായി വിലയിരുത്താൻ പ്ലാറ്റ്ഫോമിന് PAC സ്ക്രിപ്റ്റ് നൽകുന്നു. പഴയ API-കൾ ലക്ഷ്യമിടുമ്പോഴോ PAC മാതൃകയ്ക്ക് നിയമം പ്രകടിപ്പിക്കാനാകാത്തപ്പോഴോ നിയമങ്ങൾ നിങ്ങളുടെ സ്വന്തം കോഡിൽ വിലയിരുത്തുക. UDP-ഉം സൗജന്യമല്ല: ബ്രൗസറുകൾ SOCKS പ്രോക്സി വഴി TCP മാത്രം അയക്കുന്നു, മിക്ക SOCKS5 ക്ലയന്റുകളും UDP ASSOCIATE ഒരിക്കലും നടപ്പാക്കുന്നില്ല, അതിനാൽ പ്രോക്സി അടിസ്ഥാനമാക്കിയ രൂപകൽപ്പന TCP ആരോഗ്യകരമായി കാണുമ്പോൾ UDP ഉപേക്ഷിക്കുന്നു അല്ലെങ്കിൽ ചോരുന്നു.

ആ രണ്ടാം പരിധിയാണ് UDP അടിസ്ഥാനമാക്കിയ പ്രോട്ടോക്കോൾ സാധാരണ നെറ്റ്വർക്കിൽ പ്രവർത്തിച്ച് നിങ്ങളുടെ VPN കണക്ട് ചെയ്യുന്ന നിമിഷം പരാജയപ്പെടുന്നതിന്റെ കാരണം. ടണൽ UDP വഹിക്കണമെന്ന് പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, ഫോർവാർഡർ അതിനുള്ള ഫോർവാർഡിംഗ് പാത നടപ്പാക്കണം, വേറെ സോക്കറ്റ് തരത്തിലുള്ള TCP പാത മാത്രമല്ല.

ഈ ക്രമത്തിൽ പരിശോധിക്കുക

പട്ടിക ക്രമത്തിൽ ചെയ്ത് പരാജയപ്പെടുന്ന ആദ്യ ഘട്ടത്തിൽ നിർത്തുക, കാരണം മുൻപത്തേത് നിലനിൽക്കുന്നതുവരെ പിന്നീടുള്ള ഓരോ പരിശോധനയും ബഹളമാണ്.

  1. ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾ ലിസ്റ്റ് ചെയ്ത് DNS അല്ലാത്ത പാക്കറ്റുകൾ TUN ഇന്റർഫേസിൽ പ്രവേശിക്കുന്നുണ്ടോ എന്ന് ഉറപ്പാക്കുക.
  2. ഒരു തടഞ്ഞതും ഒരു അനുവദിച്ചതുമായ പേരിന് ക്വറി പേര്, തീരുമാനം, ഉത്തര കോഡ് എന്നിവ ലോഗ് ചെയ്യുക.
  3. റെസോൾവർ സോക്കറ്റ് സംരക്ഷിതമാണെന്നും തിരഞ്ഞെടുത്ത റെസോൾവർ ടണലിനുള്ളിൽ നിന്ന് ഉത്തരം നൽകുന്നുവെന്നും ഉറപ്പാക്കുക.
  4. ഇന്റർഫേസ് MTU-വും കൈകൊണ്ട് നിർമ്മിച്ച ഒരു ഉത്തരത്തിന്റെ ചെക്ക്സവും ഉറപ്പാക്കുക.
  5. അതേ പേജ് Wi-Fi-ലും മൊബൈൽ നെറ്റ്വർക്കിലും ആവർത്തിക്കുക, കാരണം കാരിയർ റെസോൾവറുകളും പാത MTU-വും വ്യത്യസ്തമാണ്.

അഞ്ചും നിലനിൽക്കുകയും പേജ് ഇപ്പോഴും തങ്ങിനിൽക്കുകയും ചെയ്താൽ, അടുത്ത സംശയിക്കുന്നത് ഫോർവാർഡർ തന്നെയാണ്: പിടിച്ചെടുത്ത അഭ്യർത്ഥന പിടിച്ചെടുത്ത ഉത്തരവുമായി താരതമ്യം ചെയ്ത് കാണാത്ത ബൈറ്റ് എണ്ണമോ പകുതി അടഞ്ഞ സോക്കറ്റോ തിരയുക. VpnService.Builder റഫറൻസ് റൂട്ട്, DNS, MTU കരാറുകൾ ഉൾക്കൊള്ളുന്നു, protect() എന്നത് builder ഓപ്ഷനല്ല, വേറിട്ട VpnService കോളാണ്; ബന്ധിപ്പിച്ച ഇന്റർഫേസ് എന്നാൽ ആദ്യ കരാർ പാലിച്ചു എന്നുമാത്രം.

അനുബന്ധ ലേഖനങ്ങൾ