NetGuard-ի SOCKS ռեժիմը ծածկում է TCP-ն, ոչ ամեն արձանագրություն

NetGuard-ը զբաղեցնում է Android-ի VPN ինտերֆեյսը՝ երթևեկությունը զտելու համար, և կարող է աջակցվող միացումները հանձնել SOCKS վերջնակետին։ Այս երկու փաստերը հաճախ կարդացվում են որպես «հեռախոսը VPN-ում է», ինչը եզրակացություն է, որը մեխանիզմը չի աջակցում։ Զտիչը տեսնում է փաթեթները; պրոքսին տեսնում է միայն այն միացումները, որոնք իրականում հանձնվել են իրեն։ Այս երկու պնդումների միջև է ամբողջ ծածկույթի հարցը։

Աղբյուր նախագծի ՀՏՀ-ն փաստագրում է և՛ մեկ ծառայության սահմանափակումը, և՛ SOCKS տարբերակը։ Տարբերակի գոյությունը ապացույց չէ, որ յուրաքանչյուր թույլատրված փաթեթ օգտագործում է այն, և ծածկույթի հարցերը ծագում են հենց այդ բացվածքից։

Երկու փոխանցման ուղի մեկ հավելվածում

Իրականացման TCP կողմը պարունակում է SOCKS միացումների մշակում, ուստի թույլատրված TCP միացումը կարող է բանակցվել պրոքսիի հետ և տեղափոխվել դրա միջով։ UDP կողմն ունի առանձին սոկետի ուղի, և դրա ուղարկման ու ստացման մշակումը կախված չէ այդ TCP բանակցությունից։ Հետևաբար, զտիչի թույլատրած դատագրամը կարող է հասնել սովորական ցանցին՝ երբեք չանցնելով պրոքսիով։ Այս ամենում հավելվածի թերություն չկա. սա պարզապես այն է, ինչ իրականացնում են երկու ուղիները։

Այս տարբերակումն ունի հետևանք, որը մարդիկ սխալ են ներկայացնում երկու ուղղությամբ էլ։ Յուրաքանչյուր UDP փաթեթ արտահոսք անվանելը անտեսում է արգելափակման կանոնները, որովհետև մերժված դատագրամը երբեք դուրս չի գալիս։ Ամբողջ կարգավորումը VPN անվանելը անտեսում է թույլատրված ուղիղ ուղին, որովհետև որոշ երթևեկություն իսկապես դուրս է գալիս առանց պրոքսիի։ Ձեր ունեցածը զտված սարք է մասնակի պրոքսիով, և ազնիվ նկարագրությունը մատրից է, ոչ պիտակ։

UDP-ի գովազդումը դրա իրականացումը չէ

UDP աջակցություն հայտարարող SOCKS սերվերը չի ավելացնում համապատասխան հաճախորդային մշակում ձեր հեռախոսի հավելվածին։ Արձանագրության տեսական հատկանիշները և տեղադրված տարբերակի վարքը տարբեր թեմաներ են, և միայն երկրորդն է նկարագրում ձեր երթևեկությունը։

Ստուգեք այն տարբերակը և կարգավորումը, որն իրականում գործարկում եք, ապա փորձարկեք անվնաս դատագրամի հոսք և դիտեք՝ արդյոք այն երևում է պրոքսիի մոտ։ Մնացած ամեն ինչ հատկանիշների ցանկից արված եզրակացություն է, իսկ հատկանիշների ցանկերը նկարագրում են մտադրություններ, ոչ կոդի ուղիներ։

DNS-ը երրորդ ուղին է, ոչ մանրամասնություն

Անվան լուծումը մատրիցին ավելացնում է իր ճյուղը։ Տեղական DNS փոխանցիչը, սովորական UDP հարցումը, պրոքսիի կողմից ինքնուրույն լուծված նպատակակետ հոսթանունը և բրաուզերում գաղտնագրված լուծիչը չորս տարբեր կարգավորումներ են։ Դրանք տարբերվում են նրանով, թե ով է տեսնում հարցումը և որ ցանցային ուղին է այն տանում, և դրանք խառնելը տալիս է թեստ, որն ուրիշների մասին ոչինչ չի ապացուցում։

Գիտակցաբար որոշեք, թե որն եք ուզում։ Եթե պահանջն այն է, որ անունները լուծվեն թունելի միջով, ապա միայն բրաուզերի կարգավորումը դա չի ապահովի, և պրոքսին, որն ինքն է լուծում հոսթանունները, պատասխանը փոխում է միայն այն միացումների համար, որոնք իսկապես սպասարկում է։

Պրոքսիի տրանսպորտը ինքնաբերաբար գաղտնի չէ

Սովորական SOCKS-ը հեռախոսից պրոքսի գաղտնագրված կապ չէ։ Եթե վերջնակետին հասնում են մեկ այլ պաշտպանված ուղով, նշեք այդ ուղին և դրա ձախողման քաղաքականությունը, որովհետև բաց ցանցին վերադարձը առանց նախազգուշացման մասնավոր կարգավորումը դարձնում է հրապարակային։ Պրոքսիի սեփական նույնականացումը նույնպես կարևոր է. համօգտագործվող սարքի բաց լսողը ծառայություն է, որի համար ոչ ոք հաշիվ չի տալիս։

Պրոֆիլների միջև կարգավորումները նույն ստուգման կարիքն ունեն։ Աշխատանքային պրոֆիլի VPN-ը պաշտպանում է միայն այն երթևեկությունը, որն օգտագործում է իր ուղին, և անձնական պրոֆիլի ֆայրվոլի ու աշխատանքային թունելի համակեցությունը չի ապացուցում, որ ֆայրվոլի հետագա միացումը հասնում է այդ թունելին։ Ստուգեք հասանելիությունը և նույնականացումը՝ փոխարենը չենթադրելով, որ երկու պրոֆիլները համագործակցում են։

Աուդիտ արեք ծածկույթը մատրիցով, ոչ թե էջի բեռնմամբ

Լիազորված գնահատման համար ընտրեք անվնաս օրինակներ, որոնք ներկայացնում են ձեզ հետաքրքրող յուրաքանչյուր դասը՝ պահանջվող TCP, թույլատրված UDP և DNS երկու հասցեաընտանիքներում։ Յուրաքանչյուրի համար գրանցեք՝ արդյոք այն պրոքսիով անցավ, արգելափակվեց, թե ուղարկվեց ուղիղ։ Այդ մեկ աղյուսակը հանձնվող արդյունքն է, և այն շատ ավելի օգտակար է, քան բեռնված էջի սքրինշոթը։

Եթե պահանջն այն է, որ ընտրված բոլոր հավելվածային երթևեկությունն անցնի հեռավոր թունելով, ընտրեք իրականացում, որը հստակորեն աջակցում է համակցված զտմանը և թունելավորմանը։ Միայն TCP պրոքսիով կազմը օգտակար է մնում ավելի նեղ առաջադրանքների համար, պայմանով, որ մնացած երթևեկությունը կառավարվի դիտավորությամբ, ոչ թե մոռացվի։