Bakit ang trapiko ng wireless debugging ay hindi patunay ng VPN leak

Binuhay mo ang wireless debugging, nagkabit ng laptop, at patuloy na gumana ang session habang naka-on ang VPN. Mukhang may nakalusot sa tabi ng tunnel. Halos tiyak na wala. Ang debugging session at ang hiling ng app sa isang website ay magkaibang relasyon sa network, at isa lang sa kanila ang dapat tumawid sa tunnel.

Naabot ko ang maling pagbasa na ito nang dalawang beses: isang beses na ang telepono at laptop ay nasa parehong Wi-Fi, at isang beses pagkatapos ng reboot nang nanatili ang pairing. Sa dalawang kaso, ginagawa ng VPN ang eksaktong nakasaad sa configuration nito.

Pangalanan ang obserbasyon bago pangalanan ang bug

May tatlong pangyayaring maaaring mauna sa claim ng leak, at hindi sila magkapalit. Maaaring tumuklas ng serbisyo ang isang tool, maaaring aprubahan ng device ang isang workstation, o maaaring talagang magdala ng mga command at byte ang awtorisadong session. Isulat kung alin ang nakita mo, dahil bawat isa ay nagpapatunay ng mas mababa kaysa inaasahan ng mga tao.

Ang pagtuklas ay karaniwang mDNS o port scan. Ang pairing ay desisyon sa pagpapatala na ginagawa sa telepono, kumpirmado ng code na itinatype ng user. Ang buhay na session ay nangangahulugang gumalaw ang trapiko sa pagitan ng dalawang pares na endpoint. Wala sa mga iyon ang naglalarawan kung saan napupunta ang HTTPS request ng app.

Panatilihing nakakabit sa pangyayari ang destinasyon, interface, pamilya ng address, timestamp at profile ng user. Kung wala ang mga detalyeng iyon, hindi maihahambing ang obserbasyon sa inilaan na patakaran ng lokal na network, o sa build ng VPN na tumatakbo noon.

Bakit hindi kailanman nagtatagpo ang dalawang landas

Ang wireless debugging ay papasok na koneksyon sa device. Nakikinig ang adbd sa port na nakatali sa Wi-Fi interface, at kumokonekta ang workstation dito pagkatapos ng pairing. Mahalaga ang direksyon: pumapasok ang laptop mo sa telepono, hindi kabaliktaran. Kabaligtaran ito ng labasang leak.

Lumalabas ang internet traffic ng app sa tunnel interface na inilalagay ng VpnService, itinutugma ayon sa UID at routing rules. Ang adbd ay system daemon na tumatakbo bilang shell user, hindi app sa routing set na iyon. Nananatili ito sa pinagbabatayang Wi-Fi link kahit naka-pin ang bawat app sa tunnel.

Ipinapatupad ng lockdown mode ang tunnel para sa mga sakop na app. Hindi nito ginagawang landas ng labasan ang nakikinig na socket.

Kaya't magkasamang umiiral nang walang kontradiksyon ang gumaganang ADB session at gumaganang kill switch. Upang patunayan ang leak, kailangan mong obserbahan ang direksyong dapat harangan.

Paano talaga hitsura ng exit test

Subukan ang sakop na app, hindi ang debugging channel. Sadyang itakda ang kondisyon ng pagkabigo, pagkatapos gumawa ng isang bagong hiling at itala ang nangyari.

1. Kumpirmahin na ang VPN ang tanging landas: buhayin ang always-on VPN na may block connections without VPN.
2. Itigil ang VPN sa sinusuportahang paraan at kumpirmahin na nag-uulat ang app na walang koneksyon.
3. Magpadala ng isang hindi mapaminsalang hiling mula sa app na iyon at obserbahan kung nabigo o nagtagumpay.
4. Ulitin na buhay ang wireless debugging, pagkatapos patayin, upang mahiwalay ang variable.

Ang harang na hiling sa ilalim ng mga kondisyong iyon ay ebidensya. Ang matagumpay na ADB session ay hindi, at gayundin ang isang ping mula sa terminal app.

Kung talagang nagtagumpay ang hiling habang buhay ang lockdown, itala ang UID ng app at ang VPN permission nito, ang aktibong network at ang bersyon ng client. Ang kombinasyong iyon ay tunay na natuklasan.

Nabubuhay ang pairing nang mas matagal kaysa session

Ang pairing ay permanenteng estado, hindi handshake na makakalimutan pagkatapos ng cable test. Inilalarawan ng dokumentasyon ng debugging ng Android ang wireless workflow at tinutukoy na tumatagal ang relasyon hanggang sadyang makalimutan o mabawi ang mga awtorisasyon.

Tingnan kung ano pa ang awtorisado bago sisihin ang tunnel. Buksan ang Wireless debugging, tingnan ang Mga Pares na Device, at kalimutan ang anumang hindi mo na makilala. Patakbuhin ang adb devices mula sa workstation upang makita kung aling mga entry ang tumutugon pa, at adb disconnect upang i-drop ang lipas na. Isinasara nang buo ng pag-off ng wireless debugging ang nakikinig na port.

Sa shared o hindi mapagkakatiwalaang network, iwanan itong patay. Ang permanenteng awtorisasyon sa network na hindi mo kontrolado ay mas malaking problema kaysa hypothetical na TUN bypass.

Bago mo i-report ang bug na iyon

Pinangalanan ng kapaki-pakinabang na ulat ang eksaktong hangganang nabigo. Isama ang modelo ng device at release ng Android, VPN client at bersyon, kung buhay ang lockdown, ang package ng app at UID, at ang network kung saan naroon ang telepono. Idagdag ang command o hiling na lumikha ng obserbasyon, kasama ang oras na nangyari ito. Kung wala iyon, walang makakagawa muli ng hangganang sinasabi mong sira.

Huwag patayin ang enforcement o ilantad ang debugging sa hindi mapagkakatiwalaang network para mas dramatic ang test. Binabago nito ang sistemang sinusukat mo at nag-iiwan ng ebidensyang walang makakaulit.

Kung ang tanging ebidensya mo ay kumonekta ang ADB habang buhay ang VPN, maling landas ang sinukat mo. Patakbuhin muna muli ang test sa antas ng app; karaniwang dumarating doon ang sagot.