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-проксі залишається корисною для вужчих завдань, за умови що решту трафіку обробляють навмисно, а не забувають.

Схожі статті