Ang SOCKS mode ng NetGuard ay sumasaklaw sa TCP, hindi sa bawat protocol

Sinasakop ng NetGuard ang interface ng VPN ng Android upang salain ang trapiko, at maaari nitong ibigay ang mga sinusuportahang koneksyon sa isang SOCKS endpoint. Ang dalawang katotohanang ito ay madalas basahin bilang “nasa VPN ang telepono”, isang konklusyong hindi sinusuportahan ng mekanismong ito. Nakikita ng filter ang mga packet; nakikita ng proxy lamang ang mga koneksyong aktuwal na ibinigay dito. Sa pagitan ng dalawang pahayag na iyon naroon ang buong tanong ng saklaw.

Dinodokumento ng FAQ ng orihinal na proyekto ang limitasyon sa isang serbisyo at ang opsyon sa SOCKS. Ang pagkakaroon ng opsyon ay hindi patunay na ginagamit ito ng bawat pinapayagang packet, at mula sa puwang na ito nagmumula ang mga tanong sa saklaw.

Dalawang landas ng pagpapasa sa loob ng isang app

Ang panig ng TCP ng implementasyon ay may hawak sa mga koneksyong SOCKS, kaya ang isang pinapayagang koneksyong TCP ay maaaring makipagkasundo sa proxy at maipasa sa pamamagitan nito. Ang panig ng UDP ay may hiwalay na landas ng socket, at ang paghawak nito sa pagpapadala at pagtanggap ay hindi nakadepende sa kasunduang TCP na iyon. Kaya ang isang datagram na pinapayagan ng filter ay maaaring makarating sa ordinaryong network nang hindi dumadaan sa proxy. Wala sa mga ito ang depekto ng app; ito lamang ang ipinapatupad ng dalawang landas.

Ang pagkakaibang ito ay may kahihinatnan na mali ang paglalarawan ng mga tao sa dalawang direksyon. Ang pagtawag sa bawat packet ng UDP na pagtagas ay binabalewala ang mga tuntunin sa pagharang, dahil ang tinanggihang datagram ay hindi kailanman lumalabas. Ang pagtawag sa buong kaayusan na VPN ay binabalewala ang pinapayagang direktang landas, dahil may trapikong talagang lumalabas nang walang proxy. Ang mayroon ka ay isang sinasala na device na may bahagyang proxy, at ang tapat na paglalarawan ay isang matrix, hindi isang label.

Ang pag-advertise ng UDP ay hindi ang pagpapatupad nito

Ang isang SOCKS server na nagsasabing sumusuporta sa UDP ay hindi nagdaragdag ng katumbas na paghawak sa panig ng kliyente sa app sa iyong telepono. Ang mga teoretikal na katangian ng protocol at ang pag-uugali ng naka-install na build ay magkaibang paksa, at ang pangalawa lamang ang naglalarawan ng iyong trapiko.

Suriin ang bersyon at configuration na aktuwal mong pinapatakbo, pagkatapos subukan ang isang hindi mapaminsalang daloy ng datagram at obserbahan kung lumilitaw ito sa proxy. Ang lahat ng iba ay hinuha mula sa listahan ng mga tampok, at ang mga listahan ng tampok ay naglalarawan ng layunin, hindi ng mga landas ng code.

Ang DNS ay ikatlong landas, hindi detalye

Ang paglutas ng pangalan ay nagdaragdag ng sarili nitong sanga sa matrix. Ang lokal na DNS forwarder, ordinaryong UDP query, hostname ng destinasyong nilulutas ng proxy mismo at naka-encrypt na resolver sa browser ay apat na magkaibang kaayusan. Nagkakaiba sila sa kung sino ang nakakakita ng query at kung aling landas ng network ang nagdadala nito, at ang paghahalo sa kanila ay gumagawa ng pagsubok na walang pinapatunayan tungkol sa iba.

Magpasya nang may malay kung alin ang gusto mo. Kung ang pangangailangan ay malutas ang mga pangalan sa tunnel, ang setting ng browser lamang ay hindi ito ibibigay, at ang proxy na mismo ang naglulutas ng mga hostname ay binabago ang sagot para lamang sa mga koneksyong aktuwal nitong hinahawakan.

Ang transportasyon sa proxy ay hindi awtomatikong pribado

Ang simpleng SOCKS ay hindi naka-encrypt na link mula telepono patungo sa proxy. Kung ang endpoint ay naabot sa ibang protektadong landas, pangalanan ang landas na iyon at ang patakaran nito sa pagkabigo, dahil ang pag-urong sa bukas na network ay ginagawang pampubliko ang pribadong kaayusan nang walang babala. Mahalaga rin ang pagpapatotoo ng proxy mismo: ang bukas na tagapakinig sa pinagsasaluhang device ay serbisyong walang sinumang nananagot.

Ang mga kaayusan sa pagitan ng mga profile ay karapat-dapat sa parehong pagsusuri. Ang VPN ng profile ng trabaho ay pinoprotektahan lamang ang trapikong gumagamit ng landas nito, at ang sabay na pagkakaroon ng firewall ng personal na profile at tunnel ng trabaho ay hindi nagpapatunay na ang karagdagang koneksyon ng firewall ay umabot sa tunnel na iyon. I-verify ang pag-abot at pagpapatotoo sa halip na ipalagay na nagtutulungan ang dalawang profile.

I-audit ang saklaw gamit ang matrix, hindi sa pag-load ng pahina

Para sa awtorisadong pagsusuri, pumili ng hindi mapaminsalang halimbawa na kumakatawan sa bawat klase na mahalaga sa iyo: kinakailangang TCP, pinapayagang UDP at DNS sa parehong pamilya ng address. Para sa bawat isa, itala kung na-proxy, naharang o direktang ipinadala. Ang nag-iisang talahanayan na iyon ang resulta, at mas kapaki-pakinabang ito kaysa sa screenshot ng pahinang nag-load.

Kung ang pangangailangan ay ang lahat ng piniling trapiko ng aplikasyon ay dapat dumaan sa malayong tunnel, pumili ng implementasyong may tahasang sinusuportahang pinagsamang pagsasala at tunneling. Ang komposisyong proxy na TCP lamang ay nananatiling kapaki-pakinabang para sa mas makitid na gawain, sa kondisyon na ang ibang trapiko ay sinadyang hawakan at hindi kalimutan.