Режимът 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 на работния профил защитава само трафика, който минава по пътя му, а съществуването на защитна стена в личния профил редом с работен тунел не доказва, че по-нататъшната връзка на стената стига до този тунел. Проверявайте достъпността и автентикацията, вместо да предполагате, че двата профила си сътрудничат.

Одитирайте покритието с матрица, а не с зареждане на страница

За оторизирана оценка изберете безвредни примери, които представляват всеки клас, който ви интересува: изискван TCP, разрешен UDP и DNS в двете семейства адреси. За всеки запишете дали е бил проксиран, блокиран или изпратен директно. Тази единствена таблица е резултатът и е много по-полезна от снимка на екран на заредена страница.

Ако изискването е целият избран трафик на приложенията да преминава през отдалечен тунел, изберете реализация с изрично поддържани комбинирано филтриране и тунелиране. Схема само с TCP прокси остава полезна за по-тесни задачи, при условие че другият трафик се обработва нарочно, а не се забравя.