Tor siap sebelum VPN: mengurutkan gerbang penyalaan dengan benar

Mengawasi proses tor lalu menyalakan VPN adalah cara paling umum untuk membangun tumpukan ini dengan salah. Daemon muncul jauh sebelum ia dapat membawa aliran klien, dan jeda tetap adalah tebakan yang berpakaian sebagai ketergantungan. Gerbangnya harus berupa keadaan yang benar-benar dibutuhkan komponen berikutnya. Jalankan empat langkah di bawah secara berurutan, dan perlakukan setiap langkah sebagai syarat tersendiri, bukan sebagai penundaan yang perlu disetel.

Langkah 1: pilih transport yang benar-benar Anda miliki

Mulailah dari protokolnya, karena sisa rancangan bergantung padanya. Antarmuka SOCKS Tor tidak mengimplementasikan UDP ASSOCIATE, jadi apa pun yang dibawa melaluinya harus berupa aliran TCP. Profil OpenVPN yang memakai UDP tidak akan bekerja lewat jalur ini, sebagus apa pun pengawas ditulis. Ubah profil ke TCP dan pastikan rekan jauh menerimanya sebelum Anda menyentuh logika penyalaan.

Lalu pastikan klien Anda sama sekali dapat menjangkau proksi SOCKS. OpenVPN 2.6 mendokumentasikan opsi socks-proxy untuk profil TCP, dan klien yang berbeda menawarkan dukungan proksi yang berbeda. Peluncur yang diam-diam mengabaikan opsi proksi akan menyambung langsung dan tampak berfungsi, yang lebih buruk daripada gagal.

Tuliskan transport yang dipilih ke runbook, karena setiap pemeriksaan berikutnya bergantung padanya.

Langkah 2: baca fase bootstrap, bukan daftar proses

Protokol kendali Tor menjawab GETINFO status/bootstrap-phase dengan keadaan bootstrap terbaru, termasuk persentase kemajuan dan tag ringkasan. Jawaban itu berguna justru karena pengendali dapat terhubung setelah daemon selesai melakukan bootstrap. Pengawas yang hanya mendengarkan peristiwa akan melewatkan kasus ketika Tor sudah siap sebelum pengawas dimulai.

Autentikasi koneksi kendali dengan benar. Port kendali adalah antarmuka administratif, dan siapa pun yang dapat berbicara dengannya dapat mengonfigurasi ulang daemon. Pertahankan di localhost, biarkan autentikasi cookie atau kata sandi tetap aktif, dan jangan hapus salah satunya agar skrip penyalaan lebih sederhana.

Baca fase itu sekali saat penyalaan, lalu berlangganan peristiwa kemajuan untuk tampilan langsung.

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

Jawaban dengan kemajuan 100 dan tag done berarti daemon telah menyelesaikan penyalaannya sendiri. Itu belum berarti ada sirkuit yang dapat dipakai menuju tujuan Anda.

Langkah 3: tunggu peristiwa sirkuit klien

Protokol peristiwa Tor mendefinisikan CIRCUIT_ESTABLISHED, yang melaporkan bahwa klien memiliki sirkuit yang dapat dipakai. Itu adalah sinyal kesiapan yang diinginkan gerbang pembawa, karena lebih dekat ke kemampuan yang Anda butuhkan daripada sebuah persentase. Berlanggananlah pada peristiwa itu dan catat transisinya, sehingga log menunjukkan kapan pembawa menjadi dapat dipakai, bukan kapan proses muncul.

Perlakukan peristiwa itu sebagai izin untuk mencoba, bukan sebagai jaminan tentang tujuan tertentu. Kebijakan keluar masih dapat menolak rekan jauh, dan jabat tangan VPN itu sendiri masih dapat gagal karena alasan yang tidak ada hubungannya dengan Tor.

Pisahkan kedua syarat itu di dalam kode. Satu nilai boolean bernama ready akan menggabungkannya dan membuat insiden berikutnya tidak terbaca.

Langkah 4: gerbangi VPN pada jabat tangannya sendiri

VPN punya syarat kesiapannya sendiri, dan hanya itu yang membuktikan terowongan sudah naik. Tunggu hingga klien melaporkan keadaan tersambung dengan alamat yang diberikan, lalu periksa bahwa syarat proksi tetap berlaku. Perulangan percobaan ulang yang membuang opsi socks-proxy setelah satu kegagalan akan menyambung langsung dan diam-diam mengalahkan seluruh rancangan.

Putuskan apa yang terjadi ketika rekan jauh tidak terjangkau sebelum Anda perlu mengetahuinya. Percobaan ulang terbatas dengan kegagalan yang terlihat lebih mudah dioperasikan daripada perulangan tanpa akhir, dan memberi sistem pemantauan sesuatu untuk diperingatkan. Keputusan yang sama berlaku untuk pembawa: jika Tor dimulai ulang, VPN harus dibongkar dan digerbangi ulang, bukan dibiarkan berjalan di sirkuit mati.

Terakhir, pertahankan kebijakan aplikasi itu sendiri selama VPN mati. Pengawas yang menunggu dengan benar tidak melakukan apa pun untuk mencegah proses tak terkait mengirim lalu lintas secara langsung.

Periksa empat transisi yang harus Anda lewati

Empat kasus mencakup rancangan ini: penyalaan dingin ketika Tor naik lebih dulu, pengawas yang menempel pada Tor yang sudah siap, rekan VPN yang tidak tersedia, dan hilangnya pembawa saat terowongan sedang naik. Masing-masing punya transisi yang diharapkan berbeda, dan masing-masing menghasilkan baris log berbeda bila gerbangnya ditulis dengan benar.

Jalankan dengan sengaja, satu per satu, dan bacalah perubahan keadaan, bukan daftar proses.

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

Ketika pembawa jatuh, VPN harus mengikutinya turun dalam satu interval percobaan ulang, bukan tetap bergantung pada terowongan yang sudah usang. Ketika Tor kembali, gerbang seharusnya baru terbuka setelah peristiwa sirkuit, bukan setelah proses dimulai. Catat syarat mana yang hilang pada setiap kegagalan, dan orang berikutnya yang berjaga tidak perlu merekonstruksi urutannya dari stempel waktu.