VPN'den önce Tor hazır: başlangıç kapısını doğru sıralayın

Bir tor sürecini izleyip ardından VPN'i başlatmak bu yığını yanlış kurmanın en yaygın yoludur. Daemon, bir istemci akışını taşıyabileceği çok önceden görünür ve sabit bir bekleme, bağımlılık kılığına girmiş bir tahmindir. Kapı, bir sonraki bileşenin gerçekten ihtiyaç duyduğu durum olmalıdır. Aşağıdaki dört adımı sırayla izleyin ve her birini ayarlanacak bir gecikme değil, ayrı bir koşul olarak ele alın.

Adım 1: gerçekten sahip olduğunuz taşımayı seçin

Protokolle başlayın, çünkü tasarımın geri kalanı ona bağlıdır. Tor'un SOCKS arayüzü UDP ASSOCIATE uygulamaz, bu nedenle üzerinden taşınan her şey bir TCP akışı olmalıdır. UDP kullanan bir OpenVPN profili, gözetleyici nasıl yazılmış olursa olsun bu yoldan çalışmaz. Profili TCP'ye geçirin ve başlangıç mantığına dokunmadan önce uzak eşin bunu kabul ettiğini doğrulayın.

Ardından istemcinizin en azından bir SOCKS vekiline ulaşabildiğini doğrulayın. OpenVPN 2.6, TCP profilleri için socks-proxy seçeneğini belgeler ve farklı istemciler farklı vekil desteği sunar. Vekil seçeneğini sessizce yok sayan bir başlatıcı doğrudan bağlanır ve çalışıyor gibi görünür, bu da başarısız olmaktan daha kötüdür.

Seçilen taşımayı runbook'a yazın, çünkü sonraki her kontrol ona bağlıdır.

Adım 2: süreç listesini değil, bootstrap aşamasını okuyun

Tor'un denetim protokolü GETINFO status/bootstrap-phase sorgusuna en son bootstrap durumuyla yanıt verir; buna bir ilerleme yüzdesi ve bir özet etiketi dahildir. Bu yanıt tam da bir denetleyicinin daemon bootstrap'i bitirdikten sonra bağlanabildiği için yararlıdır. Yalnızca olayları dinleyen bir gözetleyici, Tor'un gözetleyici başlamadan önce hazır olduğu durumu kaçıracaktır.

Denetim bağlantısını düzgün şekilde doğrulayın. Denetim portu yönetici arayüzüdür ve onunla konuşabilen herkes daemon'u yeniden yapılandırabilir. Onu localhost üzerinde tutun, çerez veya parola doğrulamasını açık tutun ve bir başlangıç betiğini basitleştirmek için ikisinden hiçbirini kaldırmayın.

Aşamayı başlangıçta bir kez okuyun, ardından canlı görünüm için ilerleme olaylarına abone olun.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

İlerlemesi 100 ve etiketi done olan bir yanıt, daemon'un kendi başlangıcını bitirdiği anlamına gelir. Bu henüz hedefinize kullanılabilir bir devre olduğu anlamına gelmez.

Adım 3: bir istemci devresi olayını bekleyin

Tor'un olay protokolü CIRCUIT_ESTABLISHED olayını tanımlar; bu, istemcinin kullanabileceği bir devresi olduğunu bildirir. Bu, bir taşıyıcı kapısının istediği hazırlık sinyalidir, çünkü ihtiyaç duyduğunuz yeteneğe bir yüzdeden daha yakındır. Olaya abone olun ve geçişi kaydedin; böylece günlük, sürecin ne zaman göründüğünü değil, taşıyıcının ne zaman kullanılabilir hale geldiğini gösterir.

Olayı deneme izni olarak görün, belirli bir hedef hakkında garanti olarak değil. Çıkış politikası uzak eşi yine de reddedebilir ve VPN'in kendi el sıkışması da Tor ile hiçbir ilgisi olmayan nedenlerle yine de başarısız olabilir.

İki koşulu kodda ayrı tutun. ready adlı tek bir boolean onları birleştirir ve bir sonraki olayı okunamaz hale getirir.

Adım 4: VPN'i kendi el sıkışmasına kapılayın

VPN'in kendi hazırlık koşulu vardır ve tünelin kalktığını yalnızca o kanıtlar. İstemci atanmış bir adresle bağlı durum bildirene kadar bekleyin, ardından vekil gereksiniminin yürürlükte kaldığını kontrol edin. Bir başarısızlıktan sonra socks-proxy seçeneğini bırakan bir yeniden deneme döngüsü doğrudan bağlanır ve tüm tasarımı sessizce alt eder.

Eş ulaşılamaz olduğunda ne olacağına, bilmeniz gerekmeden önce karar verin. Görünür bir başarısızlıkla sınırlı yeniden deneme, sonsuz bir döngüden daha kolay işletilir ve izleme sistemine uyarabileceği bir şey verir. Aynı karar taşıyıcı için de geçerlidir: Tor yeniden başlarsa, VPN ölü bir devre üzerinde çalışmaya bırakılmak yerine sökülmeli ve yeniden kapılanmalıdır.

Son olarak, VPN kapalıyken uygulamanın kendi politikasını yürürlükte tutun. Doğru şekilde bekleyen bir gözetleyici, ilgisiz bir sürecin doğrudan trafik göndermesini engellemek için hiçbir şey yapmaz.

Atlatmanız gereken dört geçişi kontrol edin

Dört durum tasarımı kapsar: Tor'un önce kalktığı soğuk başlangıç, zaten hazır bir Tor'a bağlanan gözetleyici, kullanılamayan bir VPN eşi ve tünel ayaktayken taşıyıcının kaybı. Her birinin beklenen geçişi farklıdır ve kapı doğru yazılmışsa her biri farklı bir günlük satırı üretir.

Onları bilerek, tek tek çalıştırın ve süreç listesi yerine durum değişikliklerini okuyun.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

Taşıyıcı düştüğünde, VPN eski bir tünelle asılı kalmak yerine bir yeniden deneme aralığı içinde onunla birlikte aşağı inmeli. Tor geri döndüğünde, kapı süreç başladıktan sonra değil, yalnızca devre olayından sonra yeniden açılmalı. Her başarısızlıkta hangi koşulun eksik olduğunu kaydedin; bir sonraki nöbetçi sırayı zaman damgalarından yeniden kurmak zorunda kalmayacak.