NetGuard-тың SOCKS режимі TCP-ны қамтиды, барлық протоколды емес

NetGuard трафикті сүзу үшін Android-тың VPN интерфейсін алады және қолдау көрсетілген қосылымдарды SOCKS соңғы нүктесіне бере алады. Бұл екі факті жиі «телефон VPN-де тұр» деп оқылады, ал бұл механизм қолдамайтын қорытынды. Сүзгі пакеттерді көреді; прокси тек өзіне шынымен берілген қосылымдарды көреді. Осы екі тұжырымның арасында қамту туралы бүкіл сұрақ тұр.

Бастапқы жобаның FAQ бір қызметпен шектелуді де, SOCKS опциясын да құжаттайды. Опцияның болуы әр рұқсат етілген пакеттің оны пайдаланатынына дәлел емес, және қамту сұрақтары дәл осы олқылықтан туындайды.

Бір қолданбаның ішіндегі екі жіберу жолы

Іске асырудың TCP жағында SOCKS қосылымдарын өңдеу бар, сондықтан рұқсат етілген TCP қосылымы проксимен келісіліп, оның ішінен өткізіле алады. UDP жағында жеке сокет жолы бар, және оның жіберу мен қабылдауды өңдеуі осы TCP келісіміне тәуелді емес. Сондықтан сүзгі рұқсат еткен датаграмма проксиден ешқашан өтпей-ақ қарапайым желіге жете алады. Бұның ешбірінде қолданба ақауы жоқ; бұл екі жолдың іске асыратыны ғана.

Бұл айырмашылықтың салдары бар, оны адамдар екі бағытта да қате сипаттайды. Әр UDP пакетін ағып кету деп атау бұғаттау ережелерін елемейді, өйткені қабылданбаған датаграмма ешқашан шықпайды. Бүкіл құрылымды VPN деп атау рұқсат етілген тікелей жолды елемейді, өйткені трафиктің біразы шынымен проксисіз шығады. Сізде бар нәрсе — ішінара проксиі бар сүзілген құрылғы, ал адал сипаттама — белгі емес, матрица.

UDP-ні жариялау оны іске асыру емес

UDP қолдауын мәлімдейтін SOCKS сервері телефоныңыздағы қолданбаға сәйкес клиенттік өңдеуді қоспайды. Протоколдың теориялық мүмкіндіктері мен орнатылған нұсқаның мінез-құлқы бөлек тақырыптар, және трафигіңізді тек екіншісі сипаттайды.

Нақты іске қосып отырған нұсқаңыз бен конфигурацияңызды тексеріңіз, содан кейін қауіпсіз датаграмма ағынын сынап, оның проксиде көрінетінін бақылаңыз. Қалғанының бәрі мүмкіндіктер тізімінен жасалған қорытынды, ал мүмкіндіктер тізімі код жолдарын емес, ниеттерді сипаттайды.

DNS — үшінші жол, ұсақ-түйек емес

Атауларды шешу матрицаға өз тармағын қосады. Жергілікті DNS жіберуші, қарапайым UDP сұранысы, проксидің өзі шешетін межелі хост атауы және браузердегі шифрланған шешуші — төрт түрлі құрылым. Олар сұранысты кім көретінімен және оны қай желілік жол тасымалдайтынымен ерекшеленеді, ал оларды араластыру қалғандары туралы ештеңе дәлелдемейтін сынақ береді.

Қайсысын қалайтыныңызды саналы түрде шешіңіз. Егер талап атаулардың туннель арқылы шешілуі болса, тек браузер параметрі оны бермейді, ал хост атауларын өзі шешетін прокси жауапты тек өзі шынымен өңдейтін қосылымдар үшін өзгертеді.

Прокси тасымалы автоматты түрде жеке емес

Қарапайым SOCKS телефоннан проксиге дейінгі шифрланған байланыс емес. Егер соңғы нүктеге басқа қорғалған жолмен жететін болсаңыз, сол жолды және оның сәтсіздік саясатын атаңыз, өйткені ашық желіге қайта оралу жеке құрылымды ескертусіз жария етеді. Проксидің өз аутентификациясы да маңызды: ортақ құрылғыдағы ашық тыңдаушы ешкім жауап бермейтін қызмет.

Профильдер арасындағы құрылымдар да сол тексеруге лайық. Жұмыс профилінің VPN тек өз жолын пайдаланатын трафикті қорғайды, ал жеке профильдің фаерволы мен жұмыс туннелінің қатар болуы фаерволдың одан арғы қосылымы сол туннельге жететінін дәлелдемейді. Екі профиль ынтымақтасады деп болжаудың орнына қолжетімділік пен аутентификацияны тексеріңіз.

Қамтуды бет жүктеумен емес, матрицамен аудиттеңіз

Авторизацияланған бағалау үшін сізді қызықтыратын әр тапты білдіретін қауіпсіз мысалдарды таңдаңыз: қажетті TCP, рұқсат етілген UDP және екі мекенжай отбасындағы DNS. Әрқайсысы үшін оның проксиден өткенін, бұғатталғанын немесе тікелей жіберілгенін жазыңыз. Сол бір кесте — нәтиже, және ол жүктелген беттің скриншотынан әлдеқайда пайдалы.

Егер талап таңдалған барлық қолданба трафигі қашықтағы туннельден өтуі керек болса, біріктірілген сүзуді және туннельдеуді айқын қолдайтын іске асыруды таңдаңыз. Тек TCP проксиінен тұратын құрам тар міндеттер үшін пайдалы болып қалады, бірақ қалған трафик ұмытылмай, әдейі өңделуі шарт.