Android VpnService අවසර ලැයිස්තුව: අවසර දුන් පිටු තවමත් එකතැන ඇත්තේ ඇයි

ඔබ ඩොමේන් එකක් අවසර ලැයිස්තුවට එකතු කළා, විමසුම ඔබේ යෙදුමට ළඟා වෙනවා, ගැලපුම්කරු අවසර දුන්නා යැයි ආපසු දෙනවා, නමුත් පිටුව කිසිදා පූරණය නොවෙයි. එම අවස්ථාවේදී බොහෝ දෙනා ගැලපුම්කරු නැවත ලිවීමට සහ වයිල්ඩ්කාඩ් සංසන්දන එකතු කිරීමට පටන් ගනී. මගේ අත්දැකීම අනුව ගැලපුම්කරු සාමාන්‍යයෙන් නිවැරදි වන අතර, අසාර්ථකත්වය එක් ස්ථරයක් පහළින් පිහිටයි: ඔබ සාදන ලද 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 ඇමතුමකි; සම්බන්ධිත අතුරුමුහුණත යනු පළමු ගිවිසුම ඉටු වූ බව පමණි.