Android ඉමියුලේටරය සහ සත්කාරක VPN: DNS ස්නැප්ෂොට් සහ NAT

සත්කාරකයේ බ්‍රවුසරයේ ගැටලුවකින් තොරව විවෘත වන build සේවාදායකයට ඉමියුලේටරය ළඟා විය නොහැකි විට, ප්‍රයෝජනවත් ප්‍රශ්නය VPN ක්‍රියාත්මක වේද යන්න නොවේ. ප්‍රශ්නය වන්නේ ආගන්තුකයාට යාන්ත්‍රණ දෙකෙන් කුමක් අඩුද යන්නයි. අතථ්‍ය උපාංගය ඉමියුලේටරයේ NAT පිටුපසින් තමන්ගේම ජාල stack එකක් ධාවනය කරයි, සහ එහි resolver ලැයිස්තුව boot වන විට ගන්නා ලද පිටපතකි, එබැවින් පසුව ඉහළ එන ටනලය සත්කාරකයේ මාර්ගය වෙනස් කරයි, නමුත් ආගන්තුකයා අසන දේ වෙනස් නොකරයි. මෙම ස්ථර දෙක තේරුම් ගැනීම මෙම ගැටලුවේ සියලුම පාහේ ප්‍රභේද පැහැදිලි කරයි.

ආගන්තුකයා ස්ථිර NAT පිටුපස ඇති වෙනම stack එකකි

QEMU හි user-mode ජාලකරණය ආගන්තුකයා 10.0.2.15 මත, gateway 10.0.2.2 මත, සහ DNS සේවාව 10.0.2.3 සිට 10.0.2.6 දක්වා තබයි. ආගන්තුකයාගේ පිටතට යන රථවාහනය සත්කාරකයේ kernel මගින් forward නොකෙරේ; එය සත්කාරක පැත්තේ socket බවට පරිවර්තනය වේ, එක් ආගන්තුක සම්බන්ධතාවයකට එකක්, සහ එම socket සත්කාරකයේ ලිපින අවකාශයෙන් පිටවේ. එබැවින් ආගන්තුක සම්බන්ධතාවය සෑදෙන මොහොතේ සත්කාරකයේ routing තීරණය උරුම කර ගනී, සහ එබැවින් ආගන්තුකයාගේ route වගුවේ ඔබේ ටනලය නම් කරන ප්‍රවේශයක් නොමැත.

එම යාන්ත්‍රණයම ආගන්තුකයාට ප්‍රයෝජනවත් පිටවීමක් ලබා දෙයි. 10.0.2.2 යනු සත්කාරකයේ loopback අතුරුමුහුණතේ අන්වර්ථයකි, එබැවින් ලැප්ටොප් පරිගණකයේ 127.0.0.1 මත සවන් දෙන සේවාවකට එම ලිපිනයෙන් ආගන්තුකයාගෙන් ළඟා විය හැක. සේවාලාභියා loopback මත පමණක් නිරාවරණය කරන සියල්ලට මෙම මාර්ගයෙන් ළඟා විය හැක, සහ මෙය පහත විස්තර කර ඇති proxy සැකසුමේ පදනමයි.

ආගන්තුකයාට කළ නොහැකි දෙය නම් සත්කාරකයේ ජාලය තමන්ගේ namespace එකක් මෙන් නිරීක්ෂණය කිරීමයි. bridge එකක් නැත, හවුල් route වගුවක් නැත සහ උරුම resolver එකක් නැත; ඇත්තේ එහි packet පිළිගන්නා NAT සේවාව සහ අතථ්‍ය උපාංගය ආරම්භ වන විට launcher ගත් ස්නැප්ෂොට් එක පමණි.

DNS යනු ස්නැප්ෂොට් එකකි, ජීව දර්ශනයක් නොවේ

ආරම්භයේදී ඉමියුලේටරය සත්කාරකයේ resolver ලැයිස්තුව කියවා ආගන්තුකයාට සේවාදායක හතරක් දක්වා ලබා දෙයි, ඒවා 10.0.2.3 සිට 10.0.2.6 ලිපිනවල නිරාවරණය වේ. එම මොහොතේ ටනලය පහළින් තිබුණා නම්, ස්නැප්ෂොට්හි ලැප්ටොප් පරිගණකය භාවිත කළ ඕනෑම පොදු resolver එකක් ඇත, සහ ආගන්තුකයා තම ජීවිත කාලය පුරාම එයින් අසයි. පොදු නම් විසඳේ, අභ්‍යන්තර නම් අසාර්ථක වේ, සහ සියලු රෝග ලක්ෂණ VPN දෙසට යොමු වේ, නමුත් සැබෑ පැරණි අගය වන්නේ ටනලය ඉහළ ඒමට මිනිත්තු කිහිපයකට පෙර ගන්නා ලද resolver ලැයිස්තුවයි.

එබැවින් අනුපිළිවෙල නිවැරදි කිරීම ජනප්‍රවාදයක් නොවේ. පළමුව ටනලය සම්බන්ධ කරන්න, පසුව ඉමියුලේටරය නැවත අරඹන්න, සහ ස්නැප්ෂොට් ප්‍රතිසාධනයට වඩා සීතල boot එකට මුල් තැන දෙන්න, මන්ද ඉක්මන් boot රූපයක් කලින් සුරකින ලද resolver සහ route තත්ත්වය සමඟ ආපසු එන්න පුළුවන් බැවිනි. ආගන්තුකයා දැන් භාවිත කරන දේ බැලීමට අවශ්‍ය නම්, සත්කාරකයෙන් නොව උපාංගයෙන් අසන්න:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

ඉමියුලේටරය ආරම්භයේදී පැහැදිලි resolver එකක් ද පිළිගනී, එය ආගන්තුකයා කුමන සේවාදායකය භාවිත කළ යුතුදැයි හරියටම දන්නා විට ප්‍රයෝජනවත් වන අතර එම සේවාදායකය පොදු නම් අනතුරුදායක වේ:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

පොදු resolver එකකට අභ්‍යන්තර කලාපයක පිටපතක් නොමැත, එබැවින් එකක් pin කිරීම අනුපිළිවෙල ගැටලුවක් ස්ථිර අසාර්ථකත්වයක් බවට පත් කරයි. පැතිකඩ පෞද්ගලික DNS තල්ලු කරන්නේ නම්, ටනලයට එය සැපයීමට ඉඩ දෙන්න සහ ලිපිනය දෘඩ-කේතනය කරනවා වෙනුවට ආගන්තුකයා සීතල boot කරන්න.

Routing සම්බන්ධතාවයේ මොහොතේ සත්කාරකය අනුගමනය කරයි

ආගන්තුක සම්බන්ධතා සත්කාරක socket බවට පත්වන බැවින්, routing තීරණය socket සෑදෙන විට ගනු ලැබේ. ඉල්ලීමට පෙර ටනලය ඉහළින් තිබීම යනු ඉල්ලීම පැතිකඩේ route වලට යටත්ව ටනලය හරහා පිටවේ. තෝරාගත් prefix පමණක් ගෙන යන split-tunnel පැතිකඩක් ඔබේ පෞද්ගලික subnet එක පිටත තබා යයි, එබැවින් සත්කාරකයට ළඟා වීම ආගන්තුකයා ගැන උපකල්පනයක් මිස ප්‍රතිඵලයක් නොවේ. දැනට ඇති ආගන්තුක සම්බන්ධතා සෑදූ මාර්ගයම රඳවා ගනී, එබැවින් නැවත සම්බන්ධ වන සේවාලාභියා ඉමියුලේටරය තුළ සිරවූ බාගැනීම සැමවිටම නොගැලවීය.

සත්‍යාපනය සත්කාරකයේ අතුරුමුහුණතේ සිදු වේ, ආගන්තුකයාගේ සංඛ්‍යා ලේඛනවල නොවේ:

sudo tcpdump -ni tun0 'host 203.0.113.10'

ආගන්තුකයාගේ ඉල්ලීම ටනල අතුරුමුහුණතේ දිස්වේ නම් routing ක්‍රියාත්මක වන අතර ගැටලුව ඊට ඉහළින් ඇත. එය භෞතික අතුරුමුහුණතේ දිස්වේ නම් පැතිකඩ එම prefix ආවරණය නොකරයි, සහ ආගන්තුක පැත්තේ කිසිදු නැවත සැකසුමක් එය වෙනස් නොකරයි.

සේවාලාභියා loopback proxy එකක් පමණක් ලබා දෙන විට

සමහර වාණිජ සේවාලාභීහු පද්ධති ටනලයක් කිසිසේත් නොසාදති. ඔවුන් 127.0.0.1 මත HTTP හෝ SOCKS ශ්‍රාවකයක් නිරාවරණය කර යෙදුම් එය භාවිත කරනු ඇතැයි අපේක්ෂා කරති. ආගන්තුකයාට එම socket සෘජුව දැකිය නොහැක, නමුත් ඉමියුලේටරයට එය භාවිත කරන ලෙස පැවසිය හැක, එක්කෝ දිගු කළ පාලන හරහා (Settings, පසුව Proxy, අත්පොත ප්‍රකාරය, සත්කාරකය 127.0.0.1 සහ සේවාලාභියා මුද්‍රණය කරන port), එක්කෝ ආරම්භයේදී:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

සේවාලාභී කවුළුවෙන් port එක පිටපත් කරන්න; අනුමාන කළ port එක නිශ්ශබ්දව අසාර්ථක වී කැඩුණු ටනලයක් මෙන් පෙනේ. මෙය ආවරණය කරන දේ මතක තබා ගන්න: HTTP proxy සැකසුම proxy දන්නා යෙදුම් විසින් ගරු කරනු ලබන අතර, අමු socket එය සම්පූර්ණයෙන්ම නොසලකා හරියි. වැඩ භාරය තමන්ගේම සම්බන්ධතා විවෘත කරන native binary එකක් නම්, proxy මාර්ගය ටනලයට සමාන නොවන අතර සංසන්දනය පැහැදිලිව කළ යුතුය.

ප්‍රතිඵලය ආගන්තුකයා තුළින් ඔප්පු කරන්න

එකම සැසිය තුළ පරීක්ෂණ දෙකකින් විසඳීම සහ routing වෙන් කරන්න. සංඛ්‍යාත්මක ලිපිනය පිළිතුරු දෙන විට නම අසාර්ථක වන්නේ නම් එය DNS ස්නැප්ෂොට් ගැටලුවකි, සහ විසඳුම අනුපිළිවෙල හෝ පැහැදිලි resolver එකකි. දෙකම අසාර්ථක නම් එය routing හෝ ප්‍රතිපත්තිය පෙන්නුම් කරයි, සහ ඊළඟ පරීක්ෂාව වන්නේ යෙදුම තමන්ගේම ජාල සීමා සහිත වැඩ පැතිකඩක් තුළ ධාවනය වේද යන්නයි.

අවසාන වශයෙන්, ඔබ පරීක්ෂා කරන්නේ කුමන ආගන්තුකයා මතදැයි දැන ගන්න. ඉතා පැරණි ඉමියුලේටර රූප ආගන්තුක පැත්තේ VPN සේවාලාභියාට අවශ්‍ය tun ආධාරකය නොමැතිව නිකුත් විය, එබැවින් එහි කිසිදු පැතිකඩක් කිසිදා ක්‍රියා කළ නොහැකි විය; වර්තමාන රූපවල එය ඇත. වර්තමාන රූපයක අසාර්ථක වන සේවාලාභියා සේවාලාභී හෝ පැතිකඩ ගැටලුවකි, සහ සත්කාරක ටනලය නැවත ගොඩනැගීම ප්‍රතිඵලය වෙනස් නොකරයි.