Tor üzerinden VPN: önce taşıma denetimi

Tor önce, VPN istemcisinin bir SOCKS vekil sunucusunun arkasında oturduğu, dolayısıyla tünelin kendisinin Tor üzerinden kurulduğu ve uygulama trafiğinin VPN uç noktasından çıktığı anlamına gelir. Bu belirli bir sıradır ve çoğu kişinin kurduğu şey bu değildir. Tor Browser'ı normal bir VPN istemcisinin yanında açmak, iki programdan hiçbirini diğerinin yolunu kullanmaya zorlamaz.

Denetimleri sırayla yapın. Her biri, sıradakinin başlatılmaya değer olup olmadığına karar verir.

Aslında hangi sırayı kuruyorsunuz

İki sıra aynı konuşmada karıştırılır. Tor önce, VPN istemcisinin sunucusuna bir SOCKS vekili üzerinden ulaştığı, dolayısıyla tünelin Tor üzerine kurulduğu anlamına gelir. VPN önce, Tor trafiğinin tünelden çıktığı anlamına gelir; çoğu kişi bunu kazara kurar ve sonra diğer sıra olarak tanımlar. Birincisi iletme sınırını VPN işletmecisinde yoğunlaştırır, ikincisi bunu Tor'un giriş ve çıkışında yoğunlaştırır. Hiçbiri iki uygulamayı aynı anda açık tutarak elde ettiğiniz şey değildir.

Herhangi bir şeyi yapılandırmadan önce görevin hangi sıraya ihtiyacı olduğunu yazın, çünkü ikisi farklı yazılım ayarları gerektirir ve farklı yerlerde başarısız olur. Yanlış etiketlenmiş bir sıra sizi bir saat boyunca yanlış katmanı ayıklamaya gönderir. Aşağıdaki her şey Tor önce varsayar.

Taşımayı her şeyden önce denetleyin

Tor'un SOCKS arayüzü TCP akışlarını taşır ve genel bir UDP ilişkisi sağlamaz. Taşıması UDP olan bir VPN, o vekili sıradan bir ağ arayüzü olarak ele alamaz ve hiçbir istemci ayarı vekilin neyi iletmeye istekli olduğunu değiştirmez. WireGuard olağan biçiminde açık ara kurbanıdır. TCP kipindeki bir OpenVPN profili yaygın çözümdür ve ona hâlâ açıkça vekili kullanması söylenmelidir.

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

Bir tüneli onun üzerinden ayıklamadan önce vekilin dinlediğini ve tek bir düz HTTPS isteğini taşıyabildiğini doğrulayın. Düz istek başarısız olursa VPN istemcisi asla başarılı olamaz ve günlükleri size nedenini söylemez.

Gözlemci haritasını yeniden yazın

Tor girişi, Tor'a bağlanan kaynağı görebilir; daha önce bir şey onu değiştirmediyse, o atlama adresinizi öğrenir. VPN sağlayıcısı Tor tarafından gelen bir bağlantı alır ama yine de tünelin içinde gönderdiğiniz bir hesabı, ödeme kaydını veya kimlik bilgisini biliyor olabilir. VPN üzerinden erişilen hedefler Tor'un çıkışını değil onun çıkışını görür ve bu, son iletme sınırını tek bir işletmeciye yoğunlaştırır.

Ayrıca her hedefe dağıtılmış bir yol yeniden oluşturmaz. Tor Browser her site için taze bir devre kurar; Tor üzerinden taşınan bir VPN tek bir tünel kurar ve arkasındaki her site o uç noktayı paylaşır. Farkı ortadan kaldırılacak bir kısıtlama değil, tasarım gerçeği olarak ele alın.

Kırıldığında hata katmanlarını sayın

Bozuk bir kurulumun en az dört bağımsız katmanı vardır: SOCKS bağlantısı, VPN sunucusuyla TLS el sıkışması, VPN'in kendi el sıkışması ve ardından tünelin içinde yönlendirme veya ad çözümlemesi. Her biri farklı bir belirtiyle başarısız olur ve her biri farklı bir onarım gerektirir. Tünel açılmadığı için sertifika denetimlerini gevşetmek klasik yanlış tanıdır ve bir taşıma sorununu güvenlik sorununa dönüştürür.

Başarısız olan ilk katmanı kaydedin ve orada durun. Vekil reddi ile reddedilen bir anahtar aynı olayın varyasyonları değildir.

Tehdit modeli Tor Browser'ın savunmalarını gerektiriyorsa durun

Rastgele uygulamaları Tor'un taşıdığı bir VPN üzerinden yönlendirmek, o uygulamalara Tor Browser'ın parmak izi ve yalıtım özelliklerini vermez. Hesapları, tanımlayıcıları ve kendi ağ davranışları önemini korur ve bir tünel bunların hiçbirini normalleştirmez. Amaç diğer kullanıcılarla karışan bir tarayıcıysa, bu sıra onu sağlamaz.

Tor Project'in kendisi, kullanıcıların doğru yapılandıramadığı birleşimlere karşı uyarır ve bu, çoğu insan için geçerlidir. Bu, dar bir tehdit modeli için bilinçli bir tasarımdır, tüm aygıtın anonim trafiğine giden kısa yol değildir.