NetGuard નો SOCKS મોડ TCP આવરે છે, દરેક પ્રોટોકોલ નહીં

NetGuard ટ્રાફિક ફિલ્ટર કરવા માટે એન્ડ્રોઇડના VPN ઇન્ટરફેસ પર કબજો કરે છે અને સમર્થિત કનેક્શન SOCKS એન્ડપોઇન્ટને સોંપી શકે છે. આ બે તથ્યોને ઘણી વાર “ફોન VPN પર છે” તરીકે વાંચવામાં આવે છે, જે એવો નિષ્કર્ષ છે જેને પ્રક્રિયા ટેકો આપતી નથી. ફિલ્ટર પેકેટ જુએ છે; પ્રોક્સી માત્ર એ કનેક્શન જુએ છે જે ખરેખર તેને સોંપાયા હતા. આ બે વિધાનો વચ્ચે આવરણનો આખો પ્રશ્ન રહેલો છે.

મૂળ પ્રોજેક્ટના FAQ એક-સેવા મર્યાદા અને SOCKS વિકલ્પ બંનેનું દસ્તાવેજીકરણ કરે છે. વિકલ્પનું અસ્તિત્વ એ પુરાવો નથી કે દરેક મંજૂર પેકેટ તેનો ઉપયોગ કરે છે, અને આવરણના પ્રશ્નો મહદંશે આ જ અંતરમાંથી ઉદ્ભવે છે.

એક જ એપની અંદર બે ફોરવર્ડિંગ માર્ગ

અમલીકરણની TCP બાજુમાં SOCKS કનેક્શન હેન્ડલિંગ છે, તેથી મંજૂર TCP કનેક્શન પ્રોક્સી સાથે વાટાઘાટ થઈ તેના દ્વારા વહન કરી શકાય છે. UDP બાજુનો અલગ સોકેટ માર્ગ છે, અને તેની મોકલવા અને સ્વીકારવાની હેન્ડલિંગ તે TCP વાટાઘાટ પર આધારિત નથી. તેથી ફિલ્ટર મંજૂર કરે તેવો ડેટાગ્રામ ક્યારેય પ્રોક્સીમાંથી પસાર ન થઈને સામાન્ય નેટવર્ક સુધી પહોંચી શકે છે. તેમાં એપનો કોઈ દોષ નથી; બે માર્ગ જે અમલમાં મૂકે છે તે જ છે.

આ ભેદનું પરિણામ એ છે જેને લોકો બંને દિશામાં ખોટી રીતે રજૂ કરે છે. દરેક UDP પેકેટને લીક કહેવું બ્લોકિંગ નિયમોને અવગણે છે, કારણ કે નકારેલ ડેટાગ્રામ ક્યારેય બહાર નીકળતો નથી. આખી ગોઠવણને VPN કહેવું મંજૂર સીધા માર્ગને અવગણે છે, કારણ કે થોડો ટ્રાફિક પ્રોક્સી વિના પણ બહાર જાય છે. તમારી પાસે જે છે તે આંશિક પ્રોક્સી સાથેનું ફિલ્ટર કરેલું ઉપકરણ છે, અને પ્રામાણિક વર્ણન લેબલ નહીં, મેટ્રિક્સ છે.

UDP ની જાહેરાત કરવી તેને અમલમાં મૂકવી નથી

UDP સપોર્ટનો દાવો કરતું SOCKS સર્વર તમારા ફોનની એપમાં અનુરૂપ ક્લાયન્ટ-બાજુ હેન્ડલિંગ ઉમેરતું નથી. પ્રોટોકોલની સૈદ્ધાંતિક લાક્ષણિકતાઓ અને ઇન્સ્ટોલ કરેલ બિલ્ડનું વર્તન અલગ વિષયો છે, અને તમારો ટ્રાફિક ફક્ત બીજું જ વર્ણવે છે.

તમે ખરેખર ચલાવો છો તે આવૃત્તિ અને ગોઠવણી તપાસો, પછી નિરુપદ્રવી ડેટાગ્રામ પ્રવાહની કસોટી કરો અને તે પ્રોક્સી પર દેખાય છે કે નહીં તે નિરીક્ષણ કરો. બાકીનું બધું લક્ષણોની સૂચિમાંથી અનુમાન છે, અને લક્ષણોની સૂચિઓ કોડ માર્ગો નહીં, ઇરાદા વર્ણવે છે.

DNS ત્રીજો માર્ગ છે, વિગત નહીં

નામ ઉકેલવું મેટ્રિક્સમાં પોતાની શાખા ઉમેરે છે. સ્થાનિક DNS ફોરવર્ડર, સામાન્ય UDP પ્રશ્ન, પ્રોક્સી પોતે ઉકેલેલ લક્ષ્ય હોસ્ટનામ અને બ્રાઉઝરમાં એન્ક્રિપ્ટ કરેલ રિઝોલ્વર — આ ચાર અલગ ગોઠવણો છે. તેઓ એમાં ભિન્ન છે કે પ્રશ્ન કોણ જુએ છે અને કયો નેટવર્ક માર્ગ તેને વહન કરે છે, અને તેમને મિશ્ર કરવાથી એવી કસોટી થાય છે જે બાકીની વિશે કંઈ સાબિત કરતી નથી.

તમે કયું ઇચ્છો છો તે સભાનપણે નક્કી કરો. જો જરૂરિયાત એ હોય કે નામ ટનલ દ્વારા ઉકેલાય, તો ફક્ત બ્રાઉઝર સેટિંગ તે આપશે નહીં, અને જે પ્રોક્સી પોતે હોસ્ટનામ ઉકેલે છે તે ફક્ત એ કનેક્શન માટે જવાબ બદલે છે જે તે ખરેખર સંભાળે છે.

પ્રોક્સી પરિવહન આપમેળે ખાનગી નથી

સાદું SOCKS ફોનથી પ્રોક્સી સુધીની એન્ક્રિપ્ટેડ કડી નથી. જો એન્ડપોઇન્ટ સુધી બીજા સુરક્ષિત માર્ગે પહોંચવામાં આવે, તો તે માર્ગ અને તેની નિષ્ફળતા નીતિનું નામ આપો, કારણ કે ખુલ્લા નેટવર્ક પર પાછા ફરવું ચેતવણી વિના ખાનગી ગોઠવણને જાહેર કરી નાખે છે. પ્રોક્સીનું પોતાનું પ્રમાણીકરણ પણ મહત્વનું છે: વહેંચાયેલ ઉપકરણ પર ખુલ્લું શ્રોતા એવી સેવા છે જેનો હિસાબ કોઈ આપતું નથી.

પ્રોફાઇલ વચ્ચેની ગોઠવણોને પણ એ જ તપાસ લાયક છે. કાર્ય-પ્રોફાઇલનું VPN ફક્ત તે ટ્રાફિકનું રક્ષણ કરે છે જે તેના માર્ગનો ઉપયોગ કરે છે, અને વ્યક્તિગત પ્રોફાઇલના ફાયરવોલ અને કાર્ય-ટનલનું સહઅસ્તિત્વ એ સાબિત કરતું નથી કે ફાયરવોલનું આગળનું કનેક્શન તે ટનલ સુધી પહોંચે છે. બે પ્રોફાઇલ સહકાર આપે છે એમ માનવાને બદલે પહોંચ અને પ્રમાણીકરણ ચકાસો.

પૃષ્ઠ લોડને બદલે મેટ્રિક્સથી આવરણનું ઓડિટ કરો

અધિકૃત મૂલ્યાંકન માટે, તમને મહત્વનું હોય તેવા દરેક વર્ગનું પ્રતિનિધિત્વ કરતા નિરુપદ્રવી ઉદાહરણો પસંદ કરો: જરૂરી TCP, મંજૂર UDP અને બંને સરનામા-કુટુંબોમાં DNS. દરેક માટે નોંધો કે તે પ્રોક્સી થયું, અવરોધાયું કે સીધું મોકલાયું. તે એક જ કોષ્ટક પરિણામ છે, અને લોડ થયેલા પૃષ્ઠના સ્ક્રીનશોટ કરતાં ઘણું વધુ ઉપયોગી છે.

જો જરૂરિયાત એ હોય કે પસંદ કરેલો બધો એપ્લિકેશન ટ્રાફિક દૂરસ્થ ટનલમાંથી પસાર થાય, તો સ્પષ્ટ રીતે સમર્થિત સંયુક્ત ફિલ્ટરિંગ અને ટનલિંગ ધરાવતું અમલીકરણ પસંદ કરો. ફક્ત TCP-પ્રોક્સી રચના સાંકડા કાર્યો માટે ઉપયોગી રહે છે, જો બાકીનો ટ્રાફિક ભૂલી જવાને બદલે ઇરાદાપૂર્વક સંભાળવામાં આવે.