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 прокси останува корисен за потесни задачи, под услов останатиот сообраќај да се обработува намерно, а не заборавено.