Tor-რელე VPN სერვერის წინააღმდეგ: რატომ არ არიან ურთიერთშემცვლელნი

გაქვთ მისამართი, პორტი პასუხობს და კლიენტი მას უკმაყოფილების გარეშე იღებს. ამათგან არცერთი Tor-რელეს VPN-ის ბოლო წერტილად არ აქცევს და შეცდომა ძვირია, რადგან პროფილი სუფთად იმპორტდება და შემდეგ ხელის ჩამორთმევისას ვარდება. მე ქვემოთ მოცემულ ოთხ შემოწმებას რიგით ვიყენებ; თითოეულს აქვს გაჩერების პირობა და ადრე გაჩერება სწორედ ამის არსია. თუ პირველი შემოწმება ვერ გაიარა, დანარჩენები ვერ დაგეხმარებათ.

შეამოწმეთ, რას ემსახურება პორტი სინამდვილეში

ღია პორტი ამტკიცებს მსმენელის არსებობას და მეტს არაფერს. რელეს ORPort TLS ხელის ჩამორთმევის შემდეგ Tor-ის საკუთარ უჯრედებზე საუბრობს, ამიტომ წარმატებული TLS შემოწმება თითქმის არაფერს გეუბნებათ იმაზე, მიიღება თუ არა იქ VPN პროტოკოლი:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

წაიკითხეთ სერთიფიკატი და არა მისი არსებობის ფაქტი. რელეები წარმოადგენენ თვითხელმოწერილ სერთიფიკატს განზრახ შეუმჩნეველი სახელით, რადგან რელეს ტრაფიკი ჩვეულებრივ HTTPS-ს უნდა დაემსგავსოს; VPN სერვერის სერთიფიკატი ატარებს სახელს, რომელსაც თქვენი პროფილი ელოდება. თუ მოპირდაპირე მხარე არასოდეს უპასუხებს VPN პროტოკოლის პირველ პაკეტს, პროფილის არცერთი რედაქტირება შედეგს არ შეცვლის.

აქ გაჩერდით, თუ მისამართი არ ასრულებს იმ ხელის ჩამორთმევას, რომელსაც თქვენი კლიენტი აგზავნის. ეს პროტოკოლის პასუხია და არა კონფიგურაციის პრობლემა, და ეს არის ყველაზე გავრცელებული მიზეზი, რის გამოც იმპორტირებული პროფილი სამუდამოდ 'connecting' მდგომარეობაში რჩება.

შეამოწმეთ რელეს როლი და არა ქსელის ზომა

რელეს როლები სხვადასხვა საქმეს ასრულებენ. Guard არის პირველი ნახტომი კლიენტებისთვის, შუა რელე წრედებს სხვა რელეებს შორის გადასცემს, exit არის ის, რომელიც მიზნებს ეხება, ხოლო ხიდი არის არასაჯარო შესვლის წერტილი, რომელიც BridgeDB-ის მეშვეობით ნაწილდება. Tor-ის ლექსიკონი ამ განმარტებებს ცალკე ინახავს და ხელმისაწვდომობა ყველა როლის ნაწილია, მაშინ როცა თვითნებური კლიენტების მომსახურების ნებართვა არცერთი მათგანის ნაწილი არ არის.

Exit-პოლიტიკა ღირს წაკითხვად, რადგან ის ერთადერთი ნაწილია, რომელიც გადაცემის წესს ჰგავს და ის არეგულირებს იმ მიზნებს, რომლებზეც exit გასვლას დაუშვებს და არა იმ კლიენტებს, რომლებსაც შიგნით შესვლა ეძლევათ. პორტ 25-ის დამბლოკავი შემზღუდველი exit-პოლიტიკა რაღაცას ამბობს გამავალი ბოროტად გამოყენების კონტროლზე და არა იმაზე, შეგიძლიათ თუ არა OpenVPN კლიენტის მანქანისკენ მიმართვა.

გაჩერდით, თუ რეპუტაციიდან ასკვნით: რადგან რელეები ტრაფიკს გადასცემენ, მისამართმა თქვენი უნდა მიიღოს. Tor ბილიკებს კონსენსუსისა და საკუთარი პროტოკოლის მეშვეობით ირჩევს; VPN კლიენტი მონაწილე არ არის და წრედი არ აქვს, რომელსაც შეუერთდება.

შეამოწმეთ, SOCKS-მსმენელი ლოკალურია თუ საჯარო

Tor-ის კლიენტი SOCKS ინტერფეისს ამჟღავნებს იმავე მანქანის აპლიკაციებისთვის, ნაგულისხმევად loopback-ზე. ეს მსმენელი ლოკალური მოხერხებულობაა და არა სერვისი, რომელსაც რელე ინტერნეტს სთავაზობს, და მისი როგორც საჯარო პროქსის აღქმა ის გზაა, რომლითაც ადამიანები უნებლიედ ხსნილ რელეს უშვებენ:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

მიბმის მისამართია მინიშნება. 127.0.0.1:9050-ზე SocksPort თავის საქმეს აკეთებს; ის, რომელიც 0.0.0.0-ზე უსმენს და გარედან ხელმისაწვდომია, ღია პროქსია, და Tor-ის საკუთარი წვდომის პოლიტიკის კონტროლი სწორედ იმიტომ არსებობს, რომ ეს გამჟღავნება პრობლემაა და არა ფუნქცია.

აპლიკაციისთვის, რომელსაც Tor სჭირდება, მიმართეთ ის loopback პორტისკენ და მიეცით Tor-ს სახელების ამოხსნის უფლება, რასაც ზემოთ მოცემული socks5h ფორმა აკეთებს. ნუ ჩაანაცვლებთ რელეს მისამართს ამ პორტით; რელე არ სთავაზობს იმ ინტერფეისს, რომელსაც თქვენი აპლიკაცია ითხოვს.

შეამოწმეთ, VPN პროფილი რეალურ ბოლო წერტილს ემთხვევა

VPN პროფილი მოლოდინების კრებულია: OpenVPN-ს სჭირდება სერვერის სერთიფიკატი ან CA, კლიენტის სერთიფიკატი და გასაღები და ჩვეულებრივ TLS გასაღები, ხოლო WireGuard-ს სჭირდება მოპირდაპირე მხარის საჯარო გასაღები, ბოლო წერტილი და დაშვებული IP-ები. ამათგან არცერთი არ შეიძლება გამოვიდეს მისამართიდან და ღია პორტიდან, ამიტომ ასე აწყობილი პროფილი პირველ გაცვლაზე ვარდება და არა დაკავშირებისას.

როცა პროფილს გადაგცემენ, შეამოწმეთ ის თქვენ მიერ კონტროლირებად ბოლო წერტილთან ან იმ მომწოდებელთან, რომელსაც ამოიცნობთ:

wg show
openvpn --config client.ovpn --verb 4

OpenVPN-ის ჟურნალში TLS მოლაპარაკების შეცდომა პირდაპირ ასახელებს შეუთანხმებლობას; wg show-ში ხელის ჩამორთმევის ხაზის გარეშე მოპირდაპირე მხარეს არასოდეს დაუსრულებია არცერთი. ორივე უფრო ინფორმატიულია, ვიდრე კლიენტის მბრუნავი მაჩვენებელი, და ორივე გასაღების მასალაზე ან პროტოკოლზე მიუთითებს და არა Tor-ზე.

შეამოწმეთ, რა დაცვა გჭირდებათ სინამდვილეში

ეს არის შემოწმება, რომელიც არქიტექტურას წყვეტს. Tor Browser გაძლევთ წრედის იზოლაციას და ანაბეჭდების საწინააღმდეგო დაცვას, რასაც VPN არ იძლევა; VPN ცვლის მისამართს, რომელსაც მიზანი ხედავს და გაიდენტიფიცირებს თქვენ მომწოდებელთან. არჩევანი მათ შორის საფრთხის მოდელის საკითხია და არა თავსებადობის, და მათი შერევა ქმნის კონფიგურაციას, რომელიც პირადულად გამოიყურება და ასეთი არ არის.

ჯაჭვს რიგი აქვს. Tor-ის ტრაფიკის მატარებელი VPN მხარდაჭერილი განლაგებაა, რადგან Tor-ის კლიენტს მხოლოდ გამავალი TCP სჭირდება. Tor-ის შიგნით გვირაბირებული VPN კლიენტი იგივე არ არის და არც ის, რასაც Tor კლიენტი ახორციელებს, ამიტომ ამაზე დაყრდნობით ნუ დაგეგმავთ.

სანამ რამეს იმპორტირებთ, დაადასტურეთ ოთხივე:

• პორტი ასრულებს თქვენი პროტოკოლის ხელის ჩამორთმევას და არა მხოლოდ TCP კავშირს.
• იცით ჰოსტის როლი და გადაცემას ნებართვად არ აღიქვამთ.
• თქვენ მიერ გამოყენებული SOCKS-მსმენელი loopback-ია და თქვენი, და არა საჯარო პორტი სხვის რელეზე.
• პროფილის გასაღებები ან სერთიფიკატები იმ ბოლო წერტილს ეკუთვნის, რომელსაც უკავშირდებით.