Android VpnService හි බෙදුම් ටනල් කිරීම: ඇත්තටම මොනවා රවුට් කළ හැකිද

VpnService යෙදුමක බෙදුම් ටනල් කිරීම නිශ්චිත තැන් කිහිපයක කැඩෙන අතර එක් එකකට අලුත්වැඩියාව වෙනස්. සේවාලාභියා පෙන්වන්නේ එක් අසාර්ථක ගමනාන්තයක් පමණි, එබැවින් පළමු කාර්යය ඔබ ගැටෙන මායිම කුමක්දැයි සොයා ගැනීමයි: builder ලබා ගත් මාර්ග, ඔබට සත්‍යාපනය කළ නොහැකි ප්‍රොක්සිය, ඔබ ප්‍රකාශ කළ පමණක් resolver, නැතහොත් වේදිකාව සෑම පරිශීලකයෙකුටම යොදන යෙදුම් ලැයිස්තුව. ඒ නිසාම මම පියවර හතරක පරීක්ෂාවක් තබා ගනිමි. එය පහත අනුපිළිවෙලට ගොස් පළමු අසාර්ථකත්වයේ නතර වේ.

builder වේදිකාවට දුන් දේ තහවුරු කරන්න

VpnService.Builder යනු ප්‍රකාශන ලැයිස්තුවකි. establish() අතථ්‍ය අතුරුමුහුණතක් සඳහා ParcelFileDescriptor එකක් ලබා දෙන අතර, වේදිකාව එම විස්තරකාරකයට යවන්නේ addAddress සහ addRoute හි උපසර්ගවලට ගැළපෙන රථවාහන පමණි; addDnsServer කුමන resolver අසන්නදැයි සේවාලාභීන්ට කියයි. ඔබ එකතු කළ සියලුම උපසර්ගවලින් පිටත ගමනාන්තයක් අතුරුමුහුණත කුමක් පොරොන්දු වුවත් ඔබේ යෙදුමට කිසිදා ළඟා නොවේ. මෙම එකම කරුණ කේතය වෙනස් කිරීමට පෙර කැඩුණු බෙදුම් ටනල් කිරීම පිළිබඳ බොහෝ වාර්තා පැහැදිලි කරයි.

ඔබේ builder එකලස් කළ ලිපින, මාර්ග සහ DNS ලැයිස්තු ලොග් කර, පසුව ඒවා අසාර්ථක වන ගමනාන්ත සමඟ සසඳන්න. කළමනාකරණ සත්කාරකයක් සඳහා නැති වූ /32 එකක් කැඩුණු ටනලයකට වඩා බොහෝ සාමාන්‍යය. ලැයිස්තුව නිවැරදි නම් ඉදිරියට යන්න; වැරදි නම් ඉතිරි පිරික්සුම් ලැයිස්තුව නිෂ්ඵල ශ්‍රමයකි.

excludeRoute ඇත්තේ API 33 සිට පමණි

ගමනාන්ත පාදක බැහැර කිරීම බොහෝ විට සහාය ත්‍රෙඩ් එකක් බවට පත්වන ඉල්ලීමයි. builder.excludeRoute(IpPrefix) API 33 ට පැමිණියේය; ඊට පෙර එකම සහාය දක්වන ආසන්න ක්‍රමය වන්නේ බැහැර කළ උපසර්ගය හැර සියල්ලට මාර්ග එකතු කිරීමයි, එනම් පූරක උපසර්ග ඔබම ගණනය කළ යුතුය. එම ඇමතුම් දෙක කැඩපතක ප්‍රතිබිම්බ නොවේ: එකක් අතුරුමුහුණතේ මාර්ග කුලකයෙන් අඩු කරයි, අනෙක කුලකය ශුන්‍යයෙන් ගොඩනඟයි, සහ පැරණි උපාංගයක් හඳුනා නොගන්නා ඇමතුමක් විසි කරයි හෝ නිහඬව නොසලකා හරියි. Build.VERSION.SDK_INT අනුව අත්ත වෙන් කර දෙපැත්තම සැබෑ දෘඩාංගවල පරීක්ෂා කරන්න.

පූරක ගණනය කිරීමේදී උපසර්ග පෙළගැස්ම දෙස බලන්න. /16 මාර්ගයක් තුළ /24 බැහැර කිරීමකට ඉතිරි කොටස සැබවින්ම විස්තර කරන ආවරණ උපසර්ග අවශ්‍ය වේ, විකෘති /8 එකක් නොවේ. අවසාන ලැයිස්තුව ලොග් කර බැහැර කළ සත්කාරකය තවමත් ටනලයෙන් පිටත මාර්ගයකින් විසඳෙන බව තහවුරු කරන්න.

ප්‍රොක්සි අක්තපත්‍ර ප්‍රකාශ කළ නොහැක

setHttpProxy(ProxyInfo) අතුරුමුහුණත HTTP හෝ SOCKS ප්‍රොක්සියකට හරවයි, සහ PAC URL එකකට සෑම ගමනාන්තයකටම ඒවා අතරින් තෝරා ගත හැක. ProxyInfo හෝ PAC ආකෘතිය පරිශීලක නාමය සහ මුරපදය දරන්නේ නැත, එබැවින් සත්‍යාපනය අවශ්‍ය ප්‍රොක්සිය වේදිකා API එකෙන් පිටත රැඳේ. එය අවශ්‍ය යෙදුම් සාමාන්‍යයෙන් userspace ස්ටැක් එකක්, tun2socks හෝ සමාන එන්ජිමක් ඇතුළත් කර 407 අභියෝගයට තමන්ම පිළිතුරු දෙයි.

එම තේරීමට ප්‍රතිවිපාක ඇත. userspace ස්ටැක් එකක් දකින්නේ ඔබ එයට රවුට් කරන රථවාහන පමණි, එබැවින් එය එම විස්තරකාරක මායිම තුළම ජීවත් විය යුතු අතර තමන්ගේම uplink සොකට් එකට එම protect() අවශ්‍යතාවම උරුම වේ. protect() මඟ හැරියොත් ටනලය තමන්ගේම ප්‍රවාහනය අල්ලා ගනී, එය පළමු පැකට්ටුවෙන් පසු නතර වන අතට ගැනීමක් ලෙස පෙනේ. අක්තපත්‍ර ඉල්ලන ප්‍රොක්සියකට එරෙහිව පරීක්ෂා කරන්න, මන්ද විවෘත ප්‍රොක්සියක් වේදිකා මාර්ගයෙන් ගමන් කර කිසිවක් ඔප්පු නොකරයි.

යෙදුම් ලැයිස්තු සහ DNS ද ප්‍රකාශන වේ

Builder හට addAllowedApplication සහ addDisallowedApplication දෙකම ඇත, සහ ඒවා එකිනෙක බැහැර කරයි: දෙකම ඇමතීම ව්‍යතිරේකයක් විසි කරයි. කෙසේ වුවද ලැයිස්තුව අතුරුමුහුණත සැකසීමේදී සෑම පරිශීලකයෙකුටම යෙදේ, එබැවින් වැඩ පැතිකඩ යෙදුමක් පාලනය වන්නේ ඔබේ ටනලයෙන් නොව වැඩ පැතිකඩේ ටනලයෙනි. කිසිදු API එකක් නොදෙන දෙය වන්නේ තවත් යෙදුමක තීරණය පාලනය කිරීමයි: බාහිරින් පැකට්ටුවක් ඔබේ ටනලයට තල්ලු කළ නොහැක, දැනටමත් සක්‍රීය VPN එකක් වසා හෝ නැවත වින්‍යාසගත කළ නොහැක.

DNS ද එම රටාවම අනුගමනය කරයි. addDnsServer resolver ලිපිනයක් ප්‍රකාශ කරයි; එය ඔබේ යෙදුමට ප්‍රශ්නවලට පිළිතුරු දීමට ඉඩ නොදේ. ඔබම නම් විසඳීමට අවශ්‍ය නම් resolver එකක් ධාවනය කර එහි ලිපිනය ටනලයට රවුට් කරන්න. ස්ථිර සත්කාරක නාමයකට DoT හෝ DoH භාවිතා කරන යෙදුම් ඔබ ප්‍රකාශ කළ ලිපිනය මඟ හැරිය හැක, එබැවින් ප්‍රශ්න මාර්ගයද අවහිර නොකරන්නේ නම් නාම විසඳුම හොඳම උත්සාහයක් ලෙස සලකන්න.

Manifest, always-on සහ පියවර හතරේ පරීක්ෂණය

සුදුසුකම manifest හි ප්‍රකාශ කෙරේ: BIND_VPN_SERVICE, android.net.VpnService intent පෙරහන සහ ටනලය පසුබිමේ රැඳිය යුතු නම් foreground සේවාවක්. Always-on VPN අමතරව පිරිසිදු onRevoke එකක් ඉල්ලා සිටී, මන්ද පරිශීලකයා සැකසීම් වෙනස් කරන විට හෝ තවත් යෙදුමක් පාලනය ගන්නා විට පද්ධතිය එය ඇමතීම නිසා.

පරීක්ෂා අනුපිළිවෙලට කර පළමු අසාර්ථකත්වයේ නතර වන්න. පළමුව, builder ට දුන් ලිපින, මාර්ග සහ DNS ලැයිස්තු ලබා ගන්න. දෙවනුව, establish() විස්තරකාරකයක් ලබා දුන් බවත් ප්‍රවාහන සොකට්ටුව ආරක්ෂිත බවත් තහවුරු කරන්න. තෙවනුව, ඇතුළත් කළ උපසර්ගයක් තුළ එක් ගමනාන්තයක් සහ බැහැර කළ උපසර්ගයක් තුළ එකක් ඉල්ලන්න. සිව්වනුව, ඔබේ resolver ට පමණක් විසඳිය හැකි සත්කාරක නාමයක් ඇසීමෙන් කුමන resolver ඇත්තටම පිළිතුරු දුන්නේදැයි පරීක්ෂා කරන්න.

සම්පූර්ණ වූ අතට ගැනීමක් පසු පියවර කිසිවක් ඔප්පු නොකරයි. සෑම පරීක්ෂාවක්ම එක් ස්තරයක් හුදකලා කරයි, එබැවින් දෙවන පියවරේ සාර්ථකත්වය සිව්වන ගැන කිසිවක් නොකියයි.

VpnService.Builder යොමුව builder හි සම්පූර්ණ මතුපිට ලැයිස්තුගත කරයි. ඉන් ඔබ්බට අවශ්‍ය සියල්ල තවත් API එකක්, තවත් යෙදුමක් හෝ ඔබේම userspace ස්ටැක් එකක් වන අතර එය බෙදුම් ටනල් දෝෂයක් නොව නිර්මාණ තීරණයකි.