Tor ના SOCKS પોર્ટ દ્વારા UDP: શું પસાર થતું નથી

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

એપ ખરેખર શું મોકલે છે તે તપાસો

પ્રોટોકોલના નામને બદલે ટ્રાન્સપોર્ટ ઓળખીને શરૂ કરો. વોઇસ ક્લાયંટ HTTPS પર સાઇન ઇન કરીને પછી UDP પર મીડિયા લઈ જઈ શકે છે; ગેમ TCP પર પ્રમાણીકરણ કરીને UDP પર રમી શકે છે; ફાઇલ ટ્રાન્સફર નિયંત્રણ માટે TCP અને શોધ માટે UDP વાપરી શકે છે. પ્રથમ બે વર્તન સમાન દેખાય છે જ્યાં સુધી લોગિન સફળ ન થાય અને કૉલ હજી નિષ્ફળ જાય, તેથી “કનેક્ટ થયું” એ સાબિતી નથી કે આખી એપ કામ કરે છે. કેટલાક ક્લાયંટ પોતાની રીતે UDP થી TCP પર પાછા જાય છે, જે અંશતઃ કામ કરતા સેશનને અવરોધિત ટ્રાન્સપોર્ટને બદલે અસ્થિર નેટવર્ક જેવું દેખાડે છે.

જે ભાગ નિષ્ફળ જાય તેના માટે લક્ષ્ય પોર્ટ અને ટ્રાન્સપોર્ટ લખો. એ જ એક લાઇન નક્કી કરે છે કે પ્રોક્સી બિલકુલ મદદ કરી શકે છે કે નહીં.

Tor નું SOCKS ઇન્ટરફેસ શું સ્વીકારશે

Tor સ્ટ્રીમ કનેક્શન માટે SOCKS5 CONNECT આદેશ અને નામ ઉકેલ માટે એક્સ્ટેન્શન આદેશો અમલમાં મૂકે છે, તેથી બ્રાઉઝર કોઈ ફેરફાર વિના તેના દ્વારા કામ કરે છે. UDP ASSOCIATE, જે આદેશ ક્લાયંટને ફોરવર્ડિંગ માટે પ્રોક્સીને ડેટાગ્રામ સોંપવા દેત, તે Tor જે આપે છે તેનો ભાગ નથી. એક્સ્ટેન્શનનું દસ્તાવેજીકરણ પ્રોજેક્ટની SOCKS એક્સ્ટેન્શન સ્પેસિફિકેશન માં છે, અને તે ટૂંકું છે. ડેટાગ્રામ આદેશની ગેરહાજરી ઇરાદાપૂર્વક છે: મનસ્વી UDP રિલે કરવાથી નેટવર્કને એવી ફોરવર્ડિંગ ભૂમિકા મળે જેના માટે તે ક્યારેય રચાયું નથી.

આ WireGuard માટે પણ જવાબ છે, જે ડિઝાઇન પ્રમાણે UDP છે અને તેની પાસે કોઈ TCP બેકઅપ નથી. એવો કોઈ સમર્થિત માર્ગ નથી જે WireGuard ને SOCKS પોર્ટ પર મોકલે, અને વિરુદ્ધ દાવો કરતું કંઈપણ બે સાધનોમાંથી કોઈનું લક્ષણ નહીં, પરંતુ પોતાની વિશ્વાસ અને જાળવણીની વાર્તા ધરાવતું આવરણ છે.

OpenVPN આંશિક અપવાદ છે, કારણ કે તેને TCP પર ટનલ કરવા માટે ગોઠવી શકાય છે અને તે SOCKS પ્રોક્સી વિકલ્પ સમજે છે. તેને હજી પણ TCP માટે ગોઠવાયેલ સર્વર અને પ્રદર્શન તથા ફિંગરપ્રિન્ટની અસરો વિશે સભાન નિર્ણયની જરૂર છે, તેથી તે ડિઝાઇન પસંદગી છે, સુસંગતતાનું સમાધાન નહીં.

તપાસ ક્રમમાં ચલાવો

પહેલા પુષ્ટિ કરો કે પ્રોક્સી સ્ટ્રીમ માટે કામ કરે છે, જેથી પછીની નિષ્ફળતા અપ્રાપ્ય પોર્ટ પર ન નાખી શકાય. પછી એપનો પોતાનો ટ્રાફિક પુષ્ટિ કરો અને જુઓ કે તે ખરેખર કયા સોકેટ ખોલે છે.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

પાછું ફેરવો અને યોગ્ય સાધન પસંદ કરો

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

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