Tor sedia sebelum VPN: susun pintu permulaan dengan betul

Memantau proses tor dan kemudian memulakan VPN ialah cara paling biasa untuk membina timbunan ini dengan salah. Daemon muncul jauh sebelum ia boleh membawa aliran klien, dan tunggu tetap ialah tekaan yang berpakaian kebergantungan. Pintu mestilah keadaan yang benar-benar diperlukan oleh komponen seterusnya. Lalui empat langkah di bawah mengikut urutan, dan anggap setiap satu sebagai syarat berasingan dan bukan sebagai kelewatan untuk dilaraskan.

Langkah 1: pilih pengangkutan yang benar-benar anda ada

Mulakan dengan protokol, kerana seluruh reka bentuk bergantung padanya. Antara muka SOCKS Tor tidak melaksanakan UDP ASSOCIATE, jadi apa sahaja yang dibawa melaluinya mesti aliran TCP. Profil OpenVPN yang menggunakan UDP tidak akan berfungsi melalui laluan ini, tidak kira bagaimana penyelia ditulis. Tukar profil kepada TCP dan sahkan rakan jauh menerimanya sebelum anda menyentuh logik permulaan.

Kemudian sahkan klien anda sama sekali boleh mencapai proksi SOCKS. OpenVPN 2.6 mendokumenkan pilihan socks-proxy untuk profil TCP, dan klien berbeza menawarkan sokongan proksi yang berbeza. Pelancar yang mendiamkan diri mengabaikan pilihan proksi akan bersambung terus dan kelihatan berfungsi, yang lebih buruk daripada gagal.

Tuliskan pengangkutan yang dipilih dalam runbook, kerana setiap pemeriksaan kemudian bergantung padanya.

Langkah 2: baca fasa bootstrap, bukan senarai proses

Protokol kawalan Tor menjawab GETINFO status/bootstrap-phase dengan keadaan bootstrap terkini, termasuk peratusan kemajuan dan tag ringkasan. Jawapan itu berguna kerana pengawal boleh bersambung selepas daemon sudah selesai bootstrap. Penyelia yang hanya mendengar peristiwa akan terlepas kes apabila Tor sudah sedia sebelum penyelia bermula.

Sahkan sambungan kawalan dengan betul. Port kawalan ialah antara muka pentadbiran, dan sesiapa yang boleh bercakap dengannya boleh mengkonfigurasi semula daemon. Kekalkannya pada localhost, kekalkan pengesahan cookie atau kata laluan didayakan, dan jangan buang mana-mana satu daripadanya untuk memudahkan skrip permulaan.

Baca fasa itu sekali semasa permulaan, kemudian langgan peristiwa kemajuan untuk paparan 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

Jawapan dengan kemajuan 100 dan tag done bermaksud daemon telah menamatkan permulaannya sendiri. Ia belum bermaksud ada litar yang boleh digunakan ke destinasi anda.

Langkah 3: tunggu peristiwa litar klien

Protokol peristiwa Tor mentakrifkan CIRCUIT_ESTABLISHED, yang melaporkan bahawa klien mempunyai litar yang boleh digunakan. Itulah isyarat kesediaan yang dikehendaki pintu pembawa, kerana ia lebih dekat dengan keupayaan yang anda perlukan daripada peratusan. Langgan peristiwa itu dan rekod peralihan, supaya log menunjukkan bila pembawa menjadi boleh digunakan dan bukan bila proses muncul.

Anggap peristiwa itu sebagai kebenaran untuk mencuba, bukan jaminan tentang mana-mana destinasi tertentu. Dasar keluar masih boleh menolak rakan jauh, dan jabat tangan VPN sendiri masih boleh gagal atas sebab yang tiada kaitan dengan Tor.

Kekalkan kedua-dua syarat berasingan dalam kod. Satu boolean bernama ready akan menggabungkannya dan menjadikan insiden seterusnya tidak terbaca.

Langkah 4: pintukan VPN pada jabat tangannya sendiri

VPN mempunyai syarat kesediaannya sendiri, dan hanya itu yang membuktikan terowong telah naik. Tunggu klien melaporkan keadaan bersambung dengan alamat yang diberikan, kemudian sahkan keperluan proksi kekal berkuat kuasa. Gelung cuba semula yang menggugurkan pilihan socks-proxy selepas satu kegagalan akan bersambung terus dan menewaskan seluruh reka bentuk secara senyap.

Putuskan apa yang berlaku apabila rakan jauh tidak dapat dicapai sebelum anda perlu mengetahuinya. Cuba semula terbatas dengan kegagalan yang kelihatan lebih mudah dikendalikan daripada gelung tanpa henti, dan ia memberi sistem pemantauan sesuatu untuk memberi amaran. Keputusan yang sama terpakai kepada pembawa: jika Tor dimulakan semula, VPN mesti dibongkar dan dipintukan semula dan bukan dibiarkan berjalan pada litar mati.

Akhir sekali, kekalkan dasar aplikasi itu sendiri semasa VPN tidak berfungsi. Penyelia yang menunggu dengan betul tidak melakukan apa-apa untuk menghalang proses tidak berkaitan daripada menghantar trafik secara terus.

Periksa empat peralihan yang mesti anda lalui

Empat kes meliputi reka bentuk: permulaan sejuk apabila Tor naik dahulu, penyelia yang menyertai Tor yang sudah sedia, rakan VPN tidak tersedia, dan kehilangan pembawa semasa terowong naik. Setiap satu mempunyai peralihan jangkaan yang berbeza, dan setiap satu menghasilkan baris log yang berbeza jika pintu ditulis dengan betul.

Jalankannya dengan sengaja, satu demi satu, dan baca perubahan keadaan dan bukan senarai 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

Apabila pembawa jatuh, VPN patut mengikutinya turun dalam satu selang cuba semula dan bukan tergantung dengan terowong yang lapuk. Apabila Tor kembali, pintu patut dibuka semula hanya selepas peristiwa litar, bukan selepas proses dimulakan. Catat syarat mana yang hilang pada setiap kegagalan, dan orang seterusnya yang bertugas tidak perlu membina semula urutan daripada cap masa.