SOCKS режим у NetGuard-у покрива TCP, а не сваки протокол

NetGuard заузима VPN интерфејс Android-а ради филтрирања саобраћаја и може да преда подржане везе SOCKS одредишту. Ове две чињенице често се читају као „телефон је на VPN-у“, а то је закључак који механизам не подржава. Филтер види пакете; прокси види само везе које су му заиста предате. Између те две тврдње стоји цело питање покривености.

FAQ у изворнику документује и ограничење на једну услугу и SOCKS опцију. Постојање опције није доказ да је сваки дозвољени пакет користи, и управо из тог јаза долазе питања покривености.

Два пута прослеђивања унутар једне апликације

TCP страна имплементације садржи обраду SOCKS веза, па се дозвољена TCP веза може договорити с проксијем и пренети кроз њега. UDP страна има засебан пут сокета, а њено руковање слањем и примањем не зависи од тог TCP договора. Зато датаграм који филтер дозволи може доћи до обичне мреже, а да никада не прође кроз прокси. Ништа у томе није дефект апликације; то је једноставно оно што два пута имплементирају.

Ова разлика има последицу коју људи погрешно описују у оба смера. Назвати сваки UDP пакет цурењем значи игнорисати правила блокирања, јер одбијени датаграм никада не излази. Назвати цео аранжман VPN-ом значи игнорисати дозвољени директни пут, јер део саобраћаја заиста излази без проксија. Оно што имате је филтрирани уређај с делимичним проксијем, а искрен опис је матрица, а не ознака.

Објављивати UDP није исто што и имплементирати га

SOCKS сервер који тврди да подржава UDP не додаје одговарајућу клијентску обраду апликацији на вашем телефону. Теоретске могућности протокола и понашање инсталиране верзије различите су теме, и само друга описује ваш саобраћај.

Проверите верзију и конфигурацију коју заиста покрећете, затим тестирајте безопастан ток датаграма и погледајте да ли се појављује на проксију. Све остало је закључак из листе могућности, а листе могућности описују намере, а не путање кода.

DNS је трећи пут, а не детаљ

Разрешавање имена додаје своју грану матрици. Локални DNS прослеђивач, обичан UDP упит, име хоста одредишта које разрешава сам прокси и шифровани разрешивач у прегледачу четири су различита аранжмана. Разликују се по томе ко види упит и којим се мрежним путем преноси, а њихово мешање даје тест који ништа не доказује о осталима.

Свесно одлучите који желите. Ако је захтев да се имена разрешавају кроз тунел, сама поставка прегледача то неће испунити, а прокси који сам разрешава имена хостова мења одговор само за везе које заиста обрађује.

Транспорт кроз прокси није аутоматски приватан

Обичан SOCKS није шифрована веза од телефона до проксија. Ако се одредиште достиже другим заштићеним путем, именујте тај пут и његову политику неуспеха, јер повратак на отворену мрежу претвара приватан аранжман у јаван без упозорења. И сама аутентификација проксија је важна: отворен слушалац на дељеном уређају услуга је за коју нико не полаже рачуне.

Аранжмани између профила заслужују исту проверу. VPN радног профила штити само саобраћај који користи његов пут, а паралелно постојање firewall-а личног профила и радног тунела не доказује да даља веза firewall-а достиже тај тунел. Проверите доступност и аутентификацију уместо да претпостављате да два профила сарађују.

Ревизија покривености матрицом, а не учитавањем странице

За одобрену процену одаберите безопасне примере који представљају сваку класу која вас занима: обавезан TCP, дозвољен UDP и DNS у обе адресне фамилије. За сваки запишите да ли је био проксиран, блокиран или послат директно. Та једна табела је резултат и много је кориснија од снимка екрана странице која се учитала.

Ако је захтев да сав одабрани саобраћај апликација пролази кроз удаљени тунел, одаберите имплементацију с изричито подржаним комбинованим филтрирањем и тунелирањем. Састав само с TCP проксијем остаје користан за уже задатке, под условом да се остали саобраћај обрађује намерно, а не заборављено.