Cara Mengikat qBittorrent ke Antarmuka VPN di macOS

Saya membuka qBittorrent di Mac mini, mengatur Network Interface ke utun4, memulai ulang, lalu menghabiskan satu sore menonton torrent tertahan di pengambilan metadata sementara VPN masih menunjukkan koneksi yang sehat. Pengaturannya tidak salah secara prinsip; namanya yang sudah usang. macOS memberikan nomor utun saat layanan mulai, jadi utun4 yang benar minggu sebelumnya menunjuk ke tunnel yang sudah tidak ada, dan klien mengikat soketnya ke perangkat tanpa rute. Urutan di bawah ini yang saya pakai sekarang: baca antarmuka dari tunnel yang berjalan, pilih di klien, mulai ulang sesi, lalu buktikan ikatan dengan transfer dan pemutusan yang disengaja.

Buka Advanced dan temukan kolom antarmuka

Di jendela qBittorrent, buka Preferences dengan Cmd+, dan masuk ke halaman Advanced. Network Interface adalah kolom yang penting: kolom ini mencantumkan nama antarmuka sistem dan secara bawaan berada di Any Interface, yang berarti sistem operasi memilih rute untuk setiap soket yang dibuka klien. referensi opsi proyek mendokumentasikan kolom itu dan nilai bawaannya, dan ini pengaturan yang sama di setiap platform meskipun nama di dalamnya tidak sama.

Dua hal membuat orang tersandung di sini. Daftar menampilkan nama perangkat seperti en0, en1 dan utun0 sampai utun9, tidak pernah nama produk penyedia VPN, jadi Anda perlu pemetaannya sebelum bisa memilih sesuatu yang masuk akal. Dan pilihan diterapkan saat sesi BitTorrent dimulai, bukan pada saat Anda menekan OK, jadi perubahan yang tampak tersimpan bisa masih berjalan pada ikatan lama.

Keluar dari aplikasi dengan benar memakai Cmd+Q dan pastikan prosesnya hilang sebelum membukanya lagi. Menutup jendela hanya menyembunyikannya, dan klien yang tersembunyi tetap memegang sesinya, porta pendengarannya, dan antarmuka lamanya.

pgrep -fl qbittorrent

Temukan antarmuka yang benar-benar dimiliki VPN Anda

Hubungkan VPN lebih dulu, lewat klien milik penyedia, lalu baca pandangan sistem alih-alih menu klien. Perintah di bawah mencantumkan setiap antarmuka beserta alamatnya, menunjukkan mana yang dianggap aktif oleh sistem, dan mencetak tabel rute; Anda mencari perangkat utun yang membawa rentang privat yang diberikan penyedia Anda.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Tiga bacaan memberi tahu Anda perangkat mana yang menjadi tunnel. Entri utun membutuhkan alamat inet yang termasuk kumpulan VPN. scutil --nwi menunjukkan antarmuka mana yang dianggap aktif oleh sistem dan mana yang utama. netstat -rn menunjukkan ke mana rute bawaan mengarah, dan jika rute itu masih mengarah ke en0 sementara sebuah utun punya alamat, tunnel tidak membawa seluruh lalu lintas, yang mengubah apa yang akan dilakukan ikatan nanti.

Ketika dua tunnel bisa ada bersamaan, misalnya profil kerja dan profil pribadi, kedua perangkat utun hadir dan hanya satu yang berguna. Penghitung byte menjawab pertanyaannya: catat penghitungnya, muat halaman atau mulai transfer kecil, dan lihat mana yang bergerak.

netstat -ib | grep utun

Jangan anggap nomornya stabil. Penyambungan ulang bisa memberi tunnel yang sama nama utun berbeda, dan layanan iCloud atau Continuity bisa memegang utun0 jauh sebelum VPN Anda tersambung.

Sesuaikan ikatan dengan cakupan tunnel

Kolom itu mengikat perangkat, dan hanya itu yang dilakukannya. Jika VPN adalah tunnel penuh yang merutekan 0.0.0.0/0 ke utun, mengikat ke perangkat itu mengirim setiap koneksi peer dan setiap permintaan tracker melalui VPN. Jika VPN adalah tunnel terbelah yang hanya merutekan beberapa subnet, mengikat ke utun mengirim lalu lintas peer ke perangkat tanpa rute untuk peer tersebut, dan transfer berhenti alih-alih bocor. Kedua hasil lebih aman daripada Any Interface, tetapi hanya satu yang membuat klien tetap berfungsi. Tidak ada yang berubah di luar klien: peramban dan aplikasi lain mempertahankan rutenya sendiri, jadi persyaratan yang mencakup semua aplikasi harus ditegakkan dari sisi VPN.

Baca situasinya sebelum memilih apa pun:

Keluarga alamat juga penting. Penyedia yang hanya memberikan IPv4 membiarkan antarmuka terikat tanpa alamat IPv6, jadi peer IPv6 gagal alih-alih menyelinap keluar lewat Wi-Fi. Terpisah dari itu, mengikat soket tidak memaku resolusi nama: nama host tracker diselesaikan lewat resolver macOS, yang mengikuti konfigurasi DNS sistem dan bukan perangkat yang dipilih.

Tiga cara pilihan yang tampak benar gagal

Kegagalan pertama adalah tidak memulai ulang. Kolom menampilkan utun4, preferensi tampak terkonfigurasi, dan transfer uji tetap keluar lewat Wi-Fi karena sesi yang berjalan menyimpan ikatan lama. Keluar sepenuhnya, pastikan dengan pgrep, buka lagi, dan mulai transfer sekali lagi.

Kedua adalah nama usang setelah penyambungan ulang. Begitu perangkat yang terikat hilang, koneksi peer gagal dan klien cenderung melaporkan galat tracker alih-alih pesan bersih bahwa antarmuka telah pergi, yang terbaca seperti torrent mati. Baca ulang ifconfig, pilih nama baru, dan mulai ulang.

Ketiga adalah menganggap ikatan gagal tertutup. Memilih antarmuka meminta sistem melampirkan soket ke nama perangkat; apa yang terjadi ketika nama itu hilang atau didaur ulang tidak dijamin oleh layar pengaturan. Uji pemutusan di bagian berikutnya adalah satu-satunya bukti yang berarti.

Verifikasi dengan transfer nyata dan pemutusan

Gunakan transfer yang boleh Anda jalankan, seperti citra distribusi Linux, dan jalankan dengan VPN tersambung. Amati penghitung per antarmuka sebelum dan sesudah, lalu bandingkan dengan penghitung data milik klien VPN; keduanya semestinya naik bersama saat daftar peer terisi.

netstat -ib | grep utun
pgrep -fl qbittorrent

Lalu putuskan VPN dari antarmukanya sendiri dan amati transfernya. Peer semestinya menghilang, dan koneksi baru semestinya gagal tak lama setelah tunnel jatuh. Jika laju tetap berjalan, ikatan tidak berlaku dan Anda kembali ke langkah mulai ulang, bukan ke firewall.

Sambungkan lagi dan periksa nama yang dipilih sekali lagi, karena tunnel bisa kembali di bawah utun yang berbeda. Catatan singkat berisi jenis tunnel, nama antarmuka, dan perilaku yang diharapkan saat VPN jatuh menghemat sesi berikutnya: pengaturan ini per mesin dan per penyedia, dan tidak bertahan terhadap peningkatan klien maupun pergantian aplikasi VPN.