د Android ایمیولیټر او کوربه VPN: د DNS سنیپشاټ او NAT

کله چې ایمیولیټر هغه build سرور ته ونه رسیږي چې د کوربه براوزر یې په سمه توګه پرانیزي، ګټوره پوښتنه دا نه ده چې VPN کار کوي که نه. پوښتنه دا ده چې میلمه ته د دوو میکانیزمونو کوم یو نیمګړی دی. مجازی وسیله د ایمیولیټر د NAT شاته خپل شبکه یی سټیک چلوي، او د هغې د حلکوونکو لیست د boot په وخت اخیستل شوې کاپي ده، نو هغه ټانل چې وروسته پورته شي د کوربه لاره بدلوي خو هغه څه نه بدلوي چې میلمه یې پوښتي. د دې دوو طبقو پوهیدل د دې ستونزې نږدې ټول ډولونه تشریح کوي.

میلمه د ثابت NAT شاته جلا سټیک دی

د QEMU د کاروونکي حالت شبکه میلمه په 10.0.2.15 کې، ګیټوې په 10.0.2.2 کې او DNS خدمت له 10.0.2.3 څخه تر 10.0.2.6 پورې ځای پرځای کوي. د میلمه وتونکی ټرافیک د کوربه کرنل لخوا نه لیږدول کیږي؛ هغه د کوربه اړخ سوکټونو ته بدلیږي، د هرې میلمه اړیکې لپاره یو، او هغه سوکټونه د کوربه د پتې فضا څخه وځي. له همدې امله د میلمه اړیکه د جوړیدو په شېبه کې د کوربه د لارښوونې پرېکړه په میراث اخلي، او له همدې امله د میلمه په لارښوونې جدول کې داسې ننوتنه نشته چې ستاسو ټانل ونوموي.

همدغه میکانیزم میلمه ته ګټوره ویستنه ورکوي. 10.0.2.2 د کوربه د loopback انټرفیس لقب دی، نو هغه خدمت چې په لپ ټاپ کې په 127.0.0.1 اوریدل کوي، له میلمه څخه په هغه پته رسیدلی شي. هر هغه څه چې کلاینټ یوازې په loopback کې ښکاره کوي، په دې لاره رسیدلی شي، او دا د لاندې تشریح شوي پراکسي ترتیباتو بنسټ دی.

هغه څه چې میلمه یې نه شي کولی د کوربه شبکه داسې کتل دي لکه څنګه چې دا د هغه namespace وي. نه پل شته، نه شریکه لارښوونې جدول او نه میراثي حلکوونکی؛ یوازې هغه NAT خدمت چې د هغه packetونه مني او هغه سنیپشاټ چې لانچر د مجازي وسیلې د پیل په وخت اخیستی و.

DNS یو سنیپشاټ دی، ژوندی ننداره نه

په پیل کې ایمیولیټر د کوربه د حلکوونکو لیست لولي او میلمه ته تر څلورو سرورونو ورکوي، چې په 10.0.2.3 څخه تر 10.0.2.6 پتو کې ښکاره کیږي. که په هغه وخت کې ټانل ښکته و، سنیپشاټ کې هغه عامه حلکوونکی وي چې لپ ټاپ کارولی و، او میلمه خپل ټول ژوند هغه ته پوښتنې کوي. عامه نومونه حل کیږي، داخلي نومونه ناکام کیږي، او ټولې نښې VPN ته اشاره کوي پداسې حال کې چې ریښتینی پخوانی ارزښت د حلکوونکو هغه لیست دی چې له ټانل پورته کیدو څو دقیقې مخکې اخیستل شوی و.

نو د ترتیب سمول افسانه نه ده. لومړی ټانل وصل کړئ، بیا ایمیولیټر بیا پیل کړئ، او د سنیپشاټ بحالي په پرتله سړه پیل غوره کړئ، ځکه چې د چټک پیل انځور کیدای شي د مخکې خوندي شوې حلکوونکي او لارښوونې حالت سره بیرته راشي. که غواړئ وګورئ چې میلمه اوس څه کاروي، له کوربه نه، له وسیلې پوښتنه وکړئ:

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

ایمیولیټر د پیل په وخت یو څرګند حلکوونکی هم مني، چې کله تاسو په دقیق ډول پوهیږئ چې میلمه باید کوم سرور وکاروي ګټور دی، او کله چې هغه سرور عامه وي خطرناک دی:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

عامه حلکوونکی د داخلي زون کاپي نه لري، نو یو یې ټینګول د ترتیب ستونزه په تلپاتې ناکامۍ بدلوي. که پروفایل شخصي DNS فشاروي، اجازه ورکړئ ټانل یې وړاندې کړي او د پتې سخت کوډ کولو پرځای میلمه سړه پیل کړئ.

لارښوونه د اړیکې په وخت کې کوربه تعقیبوي

ځکه چې د میلمه اړیکې د کوربه سوکټونه کیږي، د لارښوونې پرېکړه هغه وخت کیږي چې سوکټ جوړیږي. له غوښتنې مخکې پورته ټانل یعنې غوښتنه د پروفایل د لارښوونو تابع په ټانل باندې وځي. هغه split-tunnel پروفایل چې یوازې ټاکل شوي prefixونه لیږدوي ستاسو شخصي subnet به په خوښۍ بهر پریږدي، نو د کوربه رسیدل د میلمه په اړه یوه انګیرنه ده، نه نتیجه. موجودې میلمه اړیکې هغه لاره ساتي چې پرې جوړې شوې وې، له همدې امله بیا وصلیدونکی کلاینټ په ایمیولیټر کې بند پاتې ډاونلوډ تل نه سمومي.

تایید د کوربه په انټرفیس کې دی، د میلمه په احصایو کې نه:

sudo tcpdump -ni tun0 'host 203.0.113.10'

که د میلمه غوښتنه د ټانل په انټرفیس کې ښکاره شي، لارښوونه کار کوي او ستونزه د هغې پورته ده. که هغه په فزیکي انټرفیس کې ښکاره شي، پروفایل هغه prefix نه رانغاړي، او د میلمه اړخ هیڅ بیا تنظیمول به یې نه بدلوي.

کله چې کلاینټ یوازې loopback پراکسي وړاندې کوي

ځینې سوداګریز کلاینټونه سیسټم ټانل هېڅ نه جوړوي. دوی په 127.0.0.1 کې HTTP یا SOCKS اوریدونکی ښکاره کوي او تمه لري چې اپلیکیشنونه یې وکاروي. میلمه هغه سوکټ مستقیم نه شي لیدلی، خو ایمیولیټر ته کیدای شي وویل شي چې یې وکاروي، یا د پراخو کنټرولونو له لارې (Settings، بیا Proxy، لاسي حالت، کوربه 127.0.0.1 او هغه پورټ چې کلاینټ چاپوي) یا د پیل په وخت:

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

پورټ د کلاینټ له کړکۍ کاپي کړئ؛ اټکل شوی پورټ په خاموشۍ ناکام کیږي او د مات ټانل په څیر ښکاري. په یاد ولرئ چې دا څه رانغاړي: د HTTP پراکسي ترتیب هغه اپلیکیشنونه درناوی کوي چې پراکسي پېژني، او خام سوکټونه یې په بشپړه توګه له پامه غورځوي. که کار هغه native binary وي چې خپلې اړیکې پرانیزي، د پراکسي لاره له ټانل سره مساوي نه ده او پرتله باید په څرګند ډول وشي.

پایله د میلمه له داخل څخه ثابته کړئ

په یوه ناسته کې د دوو ازموینو سره حلول او لارښوونه جلا کړئ. هغه نوم چې ناکام کیږي پداسې حال کې چې عددي پته ځواب ورکوي د DNS سنیپشاټ ستونزه ده، او حل یې ترتیب یا څرګند حلکوونکی دی. که دواړه ناکام شي دا لارښوونې یا پالیسي ته اشاره کوي، او بله څیړنه دا ده چې ایا اپ په خپلو شبکوي محدودیتونو سره د کار پروفایل دننه ځي که نه.

په پای کې، پوه شئ چې په کوم میلمه ازموینه کوئ. ډیرې زاړه ایمیولیټر انځورونه د tun هغه ملاتړ پرته وتړل شوي وو چې د میلمه اړخ VPN کلاینټ ته اړین دی، نو هلته هیڅ پروفایل نشو کولی کار وکړي؛ اوسني انځورونه یې لري. هغه کلاینټ چې په اوسني انځور ناکام کیږي د کلاینټ یا پروفایل ستونزه ده، او د کوربه ټانل بیا جوړول پایله نه بدلوي.