Relay Tor versus server VPN: mengapa keduanya tidak dapat dipertukarkan

Anda punya sebuah alamat, port menjawab, dan klien menerimanya tanpa keluhan. Tidak satu pun dari itu menjadikan relay Tor sebagai titik akhir VPN, dan kesalahan ini mahal karena profil terimpor dengan bersih lalu gagal kemudian saat handshake. Saya memakai empat pemeriksaan di bawah ini secara berurutan; masing-masing punya syarat berhenti, dan berhenti lebih awal justru intinya. Jika pemeriksaan pertama gagal, sisanya tidak dapat menolong Anda.

Periksa apa yang sebenarnya dilayani port

Port terbuka membuktikan adanya pendengar, tidak lebih. ORPort sebuah relay berbicara sel milik Tor sendiri setelah handshake TLS, jadi pemeriksaan TLS yang berhasil hampir tidak memberi tahu apa pun tentang apakah protokol VPN diterima di sana:

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

Bacalah sertifikatnya, bukan fakta bahwa sertifikat itu ada. Relay menyajikan sertifikat yang ditandatangani sendiri dengan nama yang sengaja tidak mencolok, karena lalu lintas relay harus menyerupai HTTPS biasa; sertifikat server VPN membawa nama yang diharapkan profil Anda. Jika pihak seberang tidak pernah menjawab paket pertama protokol VPN, sebanyak apa pun penyuntingan profil tidak akan mengubah hasilnya.

Berhenti di sini jika alamat tidak menyelesaikan handshake yang dikirim klien Anda. Itu jawaban protokol, bukan masalah konfigurasi, dan itulah alasan paling umum sebuah profil terimpor tertahan di 'connecting' selamanya.

Periksa peran relay, bukan ukuran jaringan

Peran relay mengerjakan tugas berbeda. Guard adalah lompatan pertama bagi klien, relay tengah meneruskan sirkuit di antara relay lain, exit adalah yang menyentuh tujuan, dan jembatan adalah titik masuk non-publik yang dibagikan melalui BridgeDB. Daftar istilah Tor menjaga definisi itu tetap terpisah, dan keterjangkauan adalah bagian dari setiap peran sedangkan izin melayani klien sembarang bukan bagian dari satu pun.

Kebijakan exit layak dibaca karena hanya bagian itulah yang menyerupai aturan penerusan, dan ia mengatur tujuan yang boleh dilewati exit, bukan klien yang boleh masuk. Kebijakan exit ketat yang memblokir port 25 mengatakan sesuatu tentang kendali penyalahgunaan keluar, bukan tentang apakah Anda boleh mengarahkan klien OpenVPN ke mesin itu.

Berhentilah jika Anda bernalar dari reputasi: karena relay meneruskan lalu lintas, alamat itu harus menerima lalu lintas Anda. Tor memilih jalur melalui konsensus dan protokolnya sendiri; klien VPN bukan peserta dan tidak punya sirkuit untuk dimasuki.

Periksa apakah pendengar SOCKS bersifat lokal atau publik

Klien Tor mengekspos antarmuka SOCKS untuk aplikasi di mesin yang sama, secara bawaan pada loopback. Pendengar itu adalah kemudahan lokal, bukan layanan yang ditawarkan relay ke internet, dan memperlakukannya sebagai proksi publik adalah cara orang akhirnya menjalankan relay terbuka yang tidak mereka maksudkan:

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

Alamat pengikatan adalah petunjuknya. SocksPort pada 127.0.0.1:9050 menjalankan tugasnya; yang mendengarkan pada 0.0.0.0 dan terjangkau dari luar adalah proksi terbuka, dan kendali kebijakan akses Tor sendiri ada justru karena pemaparan itu masalah, bukan fitur.

Untuk aplikasi yang membutuhkan Tor, arahkan ke port loopback dan biarkan Tor menyelesaikan nama, yang dilakukan bentuk socks5h di atas. Jangan ganti alamat relay untuk port itu; relay tidak menawarkan antarmuka yang diminta aplikasi Anda.

Periksa bahwa profil VPN cocok dengan titik akhir yang nyata

Profil VPN adalah sekumpulan harapan: OpenVPN membutuhkan sertifikat server atau CA, sertifikat dan kunci klien, dan biasanya kunci TLS, sedangkan WireGuard membutuhkan kunci publik pihak seberang, titik akhir, dan IP yang diizinkan. Tidak satu pun dapat diturunkan dari alamat dan port terbuka, karena itulah profil yang dibangun begitu gagal pada pertukaran pertama, bukan saat menyambung.

Ketika sebuah profil diberikan kepada Anda, verifikasi terhadap titik akhir yang Anda kendalikan atau penyedia yang dapat Anda identifikasi:

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

Di log OpenVPN, kesalahan negosiasi TLS menyebut ketidakcocokan secara langsung; pada wg show, pihak seberang tanpa baris handshake belum pernah menyelesaikan satu pun. Keduanya lebih informatif daripada indikator berputar klien, dan keduanya menunjuk ke materi kunci atau protokol, bukan ke Tor.

Periksa perlindungan mana yang sebenarnya Anda butuhkan

Inilah pemeriksaan yang menentukan arsitektur. Tor Browser memberi Anda isolasi sirkuit dan pertahanan terhadap sidik jari yang tidak diberikan VPN; VPN mengubah alamat yang dilihat tujuan dan mengautentikasi Anda ke penyedia. Memilih di antara keduanya adalah pertanyaan model ancaman, bukan pertanyaan kompatibilitas, dan mencampurnya menghasilkan penyiapan yang tampak privat dan ternyata tidak.

Perantaian punya urutan. VPN yang membawa lalu lintas Tor adalah susunan yang didukung, karena klien Tor hanya membutuhkan TCP keluar. Klien VPN yang diterowongkan di dalam Tor bukan hal yang sama dan bukan yang diimplementasikan klien Tor, jadi jangan merencanakan atas dasar itu.

Sebelum mengimpor apa pun, pastikan keempatnya:

• Port menyelesaikan handshake protokol Anda, bukan sekadar koneksi TCP.
• Anda tahu peran hos dan tidak memperlakukan penerusan sebagai izin.
• Pendengar SOCKS yang Anda pakai adalah loopback dan milik Anda, bukan port publik di relay orang lain.
• Kunci atau sertifikat profil milik titik akhir yang Anda sambungi.