Tor თუ VPN: გადაწყვიტეთ იმის მიხედვით, ვის აიძულებს ყოველი გზა, რომ ენდოთ
VPN თქვენს ნდობას ერთ ოპერატორზე აგროვებს; Tor კი რელეებზე ანაწილებს. გადაწყვიტეთ დაფარვის, იმის მიხედვით, თუ ვის შეუძლია თქვენი საიტთან დაკავშირება, და იმის მიხედვით, რისი გადამოწმება შეგიძლიათ.
Tor-სა და VPN-ს შორის არჩევანი იმაზე მოდის, თუ რომელ მხარეს შეგიძლიათ აუტანოთ კავშირის ორივე ბოლოს დანახვა. VPN ამ ხედვას თქვენ მიერ არჩეულ ერთ ოპერატორზე ამახვილებს. Tor მას რელეებზე ანაწილებს, ამიტომ არც ერთ ცალკეულ რელეს არ უნდა შეეძლოს გაიგოს, ვინ ხართ და რა ჩამოტვირთეთ.
არც ერთი წყობა თავისთავად არ გხდით ანონიმურებს. აირჩიეთ ის, რომლის დარჩენილი ნდობის ხმამაღლა თქმა შეგიძლიათ, შემდეგ კი შეაკეთეთ ის ნაწილები, რომლებსაც ის ღიად ტოვებს.
დაითვალეთ, ვის შეუძლია თქვენი დანიშნულებასთან დაკავშირება
VPN-ის შემთხვევაში, ყოველი დაფარული ნაკადი დანიშნულებამდე ოპერატორის გასასვლელს აღწევს. ეს ოპერატორი აუცილებლად ხედავს თქვენს წყაროს მისამართს და, ყველაფრისთვის, რაც მის მეშვეობით არ არის დაშიფრული, თქვენ მიერ მოთხოვნილ დანიშნულებას. TLS გვერდის შიგთავსს ამ ხედვის გარეთ ინახავს, მაგრამ ჩვეულებრივ ჰოსტის სახელს ხილვად ტოვებს კავშირის დამყარებისას. ამიტომ ერთ მხარეს შეუძლია თქვენი საიტთან დაკავშირება და ეს კავშირი ზუსტად ის ნდობაა, რომელსაც აძლევთ.
Tor ამ ნახევრებს სამ რელეზე ჰყოფს: მცველი, რომელმაც იცის თქვენი მისამართი, მაგრამ არა დანიშნულება; შუა რელე, რომელმაც არც ერთი ბოლო არ იცის; და გასასვლელი, რომელმაც იცის დანიშნულება, მაგრამ არა თქვენ. დიზაინი ვარაუდობს, რომ არც ერთი რელე ორივე ფაქტს არ აერთიანებს, რაც ერთ კომპანიაზე ნდობაზე სუსტი და უფრო სასარგებლო ვარაუდია. ის არ ვარაუდობს, რომ რელეები პატიოსნები არიან და არც იმარჯვებს დამკვირვებელზე, რომელიც გზის ორივე ბოლოს ხედავს.
ორივე დიზაინს ერთი სუსტი წერტილი აქვს და ის დანიშნულებაზეა. თუ შეხვალთ, სერვისი ამ სესიას თქვენს ანგარიშთან აკავშირებს, რა გზითაც არ უნდა მისულიყვნენ პაკეტები. მარშრუტიზაცია ცვლის იმას, საიდან თითქოს მოდის მოთხოვნა და არა იმას, რასაც გვერდი გთხოვთ მიაწოდოთ.
დაფარვა უფრო მნიშვნელოვანია, ვიდრე მარშრუტიზაციის სქემა
VPN ქსელურ დონეზე მარშრუტიზაციას ახდენს, ამიტომ მოწყობილობის ყოველი აპლიკაცია გვირაბს მემკვიდრეობით იღებს, თუ განზრახ არ გამორიცხავთ მას. სწორედ ეს სიგანეა მიზეზი, რომ ის ერთდროულად მუშაობს ფოსტის კლიენტისთვის, პაკეტების მენეჯერისა და ბრაუზერისთვის.
Tor Browser პაკეტია და მისი დაცვები ძირითადად ბრაუზერის შიგნით ცხოვრობს: ერთგვაროვანი თითის ანაბეჭდი, საიტებს შორის იზოლაცია და სკრიპტები, რომლებიც უსაფრთხოების დონით შემოიფარგლება და არა თქვენ მიერ დაყენებული გაფართოებებით. Chrome-ის SOCKS პორტზე მიმართვა ყიდულობს მარშრუტიზაციას ამ ყველაფრის გარეშე, რაც არასწორ ადგილას თავდაჯერებულობის ჩვეულებრივი წყაროა.
სამუშაო მაგიდის დანარჩენი ნაწილი უცვლელი რჩება. სინქრონიზაციის კლიენტი, განმაახლებელი ან სხვა პროგრამაში გახსნილი ჩამოტვირთული დოკუმენტი ისე უკავშირდება, როგორც ეს პროგრამაა კონფიგურირებული და ამის არც ერთი ნაწილი არ გადის SOCKS მსმენელზე, თუ იქ არ დააყენეთ. ჩამოთვალეთ აპლიკაციები, რომლებიც ქსელთან საუბრობენ, შემდეგ იკითხეთ, რომელ მათგანს ფარავს არჩეული ხელსაწყო სინამდვილეში. დაფარვა თქვენი კონფიგურაციის თვისებაა და არა თქვენი განზრახვის.
აირჩიეთ სამი პირობით
გადაწყვეტილება ჩვეულებრივ სამ კითხვაზე წყდება: ტრაფიკი ერთი აპლიკაციიდან მოდის თუ მთელი მოწყობილობიდან, უნდა თუ არა დანიშნულებას თქვენი მისამართის იდენტიფიცირება ვერ შეძლოს, და გჭირდებათ თუ არა კერძო ქსელში მოხვედრა? უპასუხეთ ამ თანმიმდევრობით და ხელსაწყო უმეტესად თავად ირჩევს თავს.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
როცა ორი მოთხოვნა ეწინააღმდეგება ერთმანეთს, აწონეთ, რომელი შეგიძლიათ აიძულოთ. მოწყობილობის გვირაბი გაჟონვადი გამონაკლისების სიით უარესია, ვიდრე მხოლოდ ბრაუზერში მოქმედი გზა, რომლის დემონსტრირებაც შეგიძლიათ.
შემოწმება იაფია ორივე გზისთვის და ის უნდა მოხდეს სანამ რომელიმე მათგანს დაეყრდნობით:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
პირველი ბრძანების ცრუ შედეგი ნიშნავს, რომ მოთხოვნა წრედის გარეთ გავიდა და სწორედ ეს არის ის წარუმატებლობა, რომლის ადრეულად დაჭერაც ღირს. შეადარეთ მეორე იმ მისამართს, რომელიც თქვენმა პროვაიდერმა მოგანიჭათ, და არა იმას, რომელიც გასული კვირიდან გახსოვთ.
რასაც არც ერთი ვარიანტი არ ასწორებს
აპლიკაციების დაშიფვრა კვლავ ასრულებს სამუშაოს, რომელსაც არც ერთი გზა არ ასრულებს. კონფიდენციალურობის ქსელის გავლით მარტივი HTTP გასასვლელში კითხვადი რჩება და HTTPS რჩება ერთადერთი, რაც ტვირთს ბოლოდან ბოლომდე იცავს. TLS ასევე არაფერს ამბობს თქვენ მიერ აკრეფილ ჰოსტის სახელზე, ამიტომ დანიშნულება ხილვადი რჩება ყველასთვის, ვინც გზას ასრულებს.
ანგარიშები გაიდენტიფიცირებენ და არც ერთი მარშრუტიზაციის არჩევანი ამას არ ცვლის: სერვისმა იცის, ვინ შევიდა, მიუხედავად სათაურში არსებული მისამართისა. საკმარისი ქსელის დამნახველი დამკვირვებლის კორელაცია, თქვენივე მოწყობილობის კომპრომეტაცია და ყველაფერი, რასაც ფორმაში აკრეფთ, ორივე დიზაინში გადარჩება. ორივე ხელსაწყოს მოეპყარით როგორც ნდობის გადაადგილების ხერხს და არა მისი წაშლის.
დაიწყეთ ნაგულისხმევი კონფიგურაციიდან, რომელსაც ყოველი პროექტი აღწერს, დაადასტურეთ გზა ზემოთ მოცემული ორი ბრძანებით და მხოლოდ ამის შემდეგ განიხილეთ VPN-ის Tor-ის ქვეშ დაწყობა. მათი ერთმანეთში ჩალაგება საკუთარი წარუმატებლობის რეჟიმების მქონე კონფიგურაციაა და არა უფასო განახლება.