Tor દ્વારા VPN: પહેલાં પરિવહન તપાસ

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

તપાસો ક્રમમાં કરો. દરેક નક્કી કરે છે કે આગળની શરૂ કરવા યોગ્ય છે કે નહીં.

તમે ખરેખર કયો ક્રમ બનાવી રહ્યા છો

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

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

બીજા કંઈપણ પહેલાં પરિવહન તપાસો

Tor નું SOCKS ઇન્ટરફેસ TCP પ્રવાહો વહન કરે છે અને સામાન્ય UDP સંગઠન આપતું નથી. જેનું પરિવહન UDP છે તેવું VPN તે પ્રોક્સીને સામાન્ય નેટવર્ક ઇન્ટરફેસ તરીકે ગણી શકતું નથી, અને કોઈ ક્લાયન્ટ સેટિંગ બદલતું નથી કે પ્રોક્સી શું આગળ મોકલવા તૈયાર છે. સામાન્ય સ્વરૂપમાં WireGuard સ્પષ્ટ ભોગ બનનાર છે. TCP મોડમાં OpenVPN પ્રોફાઇલ સામાન્ય ઉપાય છે, અને તેને પણ સ્પષ્ટપણે પ્રોક્સી વાપરવાનું કહેવું પડે છે.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

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

નિરીક્ષકનો નકશો ફરીથી લખો

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

તે દરેક લક્ષ્ય સુધી વિતરિત માર્ગ પણ ફરી બનાવતું નથી. Tor Browser દરેક સાઇટ માટે નવું સર્કિટ બનાવે છે; Tor પર વહન થતું VPN એક ટનલ બનાવે છે, અને તેની પાછળની દરેક સાઇટ તે એન્ડપોઇન્ટ વહેંચે છે. તફાવતને દૂર કરવાની મર્યાદા તરીકે નહીં, ડિઝાઇન હકીકત તરીકે ગણો.

તૂટે ત્યારે નિષ્ફળતાના સ્તરો ગણો

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

જે પહેલું સ્તર નિષ્ફળ જાય તે નોંધો અને ત્યાં જ અટકો. પ્રોક્સીનો ઇનકાર અને નકારાયેલી ચાવી એક જ ઘટનાના ભિન્ન રૂપો નથી.

જો ધમકી મોડેલને Tor Browser ના રક્ષણની જરૂર હોય તો અટકો

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

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