Mesin OpenVPN atau Tunnelblick: siapa yang memiliki sesi VPN Mac?

Homebrew memasang program OpenVPN; Tunnelblick memasang pengelola yang menjalankan satu atau lebih mesin. Itu lapisan yang berbeda, dan pertanyaan yang berguna bukanlah apakah Anda suka memakai terminal. Melainkan siapa yang memiliki konfigurasi, perubahan DNS, permintaan kredensial, dan pembersihan saat sesi berakhir. Satu pemilik untuk lapisan-lapisan itu yang membuat penyiapan dapat diprediksi.

Lakukan lima pemeriksaan di bawah ini secara berurutan. Yang pertama memiliki dua pemilik adalah yang menghasilkan kondisi setengah terhubung aneh yang orang salahkan pada OpenVPN itu sendiri. Setiap pemeriksaan menyebutkan bukti yang menyelesaikannya.

Pemeriksaan satu: biner OpenVPN mana yang benar-benar berjalan

Jalankan pgrep -fl openvpn saat terhubung dan baca baris perintah lengkapnya. Jalur pertama adalah mesin yang benar-benar berjalan. Di Apple Silicon, pemasangan Homebrew biasanya berada di bawah /opt/homebrew, sedangkan Mac Intel memakai /usr/local, dan Tunnelblick menjalankan mesin dari dalam paket aplikasinya sendiri.

Tunnelblick membundel mesin dan memungkinkan konfigurasi memilih salah satunya. Memperbarui formula Homebrew mengubah biner mandiri, bukan mesin yang dijalankan profil Tunnelblick. Jika Anda membandingkan versi untuk menjelaskan perbedaan perilaku, bandingkan mesin di daftar proses, bukan yang ada di manajer paket. String versi saja tidak akan memberi tahu Anda profil mana yang dimuat mesin itu.

Profil yang disalin juga bisa membuat dua mesin tampak identik padahal keduanya membaca berkas berbeda. Jalur profil di baris perintah memberi tahu Anda konfigurasi mana yang dimuat proses yang berjalan; profil yang terbuka di editor bukan bukti. Bandingkan jalur itu sebelum membandingkan perilaku.

Pemeriksaan dua: siapa yang mengubah DNS dan rute

Mesin dapat menjalankan direktif up dan down milik OpenVPN sendiri, tetapi pengelola mungkin memiliki siklus hidup yang sama. Pengaturan server nama Tunnelblick mengendalikan skrip koneksi dan pemutusan standarnya, dan ketika integrasi itu aktif, direktif pesaing di profil bisa diabaikan.

Itu penting karena DNS adalah tempat tunnel yang berfungsi paling sering terlihat rusak. Periksa scutil --dns saat terhubung, catat resolver mana yang pertama, dan pastikan ia kembali setelah terputus. Jika profil mengharapkan menyetel DNS sendiri sementara pengelola juga mengelolanya, salah satu dari keduanya akan kalah.

Putuskan lapisan mana yang memiliki DNS sebelum koneksi pertama, lalu hapus direktif yang kalah alih-alih membiarkan keduanya. Perubahan rute mengikuti aturan yang sama: satu pemilik, terlihat dalam konfigurasi, dengan jalur pemulihan yang terdokumentasi.

Pemeriksaan tiga: dari mana kredensial berasal

Permintaan interaktif dan proses tanpa pengawasan punya kebutuhan berbeda. Kredensial yang disimpan satu aplikasi tidak otomatis tersedia bagi proses lain, dan item keychain yang dibatasi pada pengelola bisa tidak terlihat oleh mesin mandiri yang dijalankan dari shell.

Sebutkan sumber kredensial untuk profil: sertifikat dan kunci klien, permintaan nama pengguna dan kata sandi, atau token yang disediakan pembantu eksternal. Lalu pastikan pemilik yang dipilih dapat mencapai sumber itu tanpa manusia jika koneksi harus bertahan melewati reboot.

Pemeriksaan empat: siapa yang memulai, mengawasi, dan menghentikan proses

Penerapan mandiri memerlukan pengawas jika harus tetap hidup. Launchd dapat memulai mesin saat login atau sesuai permintaan, memulainya kembali setelah crash, dan menghentikannya dengan bersih, tetapi seseorang harus menulis dan memiliki tugas itu. Menjalankan perintah di terminal berguna untuk uji coba dan tidak untuk pengguna yang menutup jendela.

Jika Tunnelblick tetap menjadi pemilik, gunakan kontrol yang didukungnya alih-alih memulai mesin kedua. Biner Homebrew, dengan profil yang disalin, membuka koneksi independen dengan konfigurasi dan konteks integrasinya sendiri alih-alih memerintah sesi Tunnelblick yang ada.

Pemilik mana pun yang Anda pilih, tentukan apa yang terjadi saat tidur, perubahan jaringan, dan logout. Pengelola biasanya menangani peristiwa itu; proses telanjang biasanya tidak, dan rute atau resolver basi yang dihasilkan mudah salah dibaca sebagai kesalahan server.

Pemeriksaan lima: bagaimana serah terima diverifikasi

Uji pemilik baru dengan yang lama dinonaktifkan, lalu uji lagi yang lama jika Anda berencana mempertahankannya. Sumber daya privat yang merespons dalam satu alur kerja dan tidak dalam alur lain adalah bukti tentang integrasi yang hilang, bukan tentang server.

Untuk serah terima ke mesin mandiri, catat jalur profil, jalur biner, pengawas, pemilik DNS, dan sumber kredensial. Lalu verifikasi sumber daya privat, jalur ke internet publik, dan pemutusan bersih dalam urutan itu. Jika DNS atau rute tetap ada setelah terputus, pemilik baru belum selesai.

Untuk serah terima ke Tunnelblick, pilih mesin untuk konfigurasi, aktifkan integrasi DNS yang Anda maksud, dan hapus direktif profil yang menentangnya. Lalu ulangi tiga pemeriksaan yang sama. Koneksi yang berfungsi tetapi meninggalkan resolver berubah adalah serah terima yang gagal, meskipun tunnel sempat naik.

Pengemasan tidak menyelesaikan kompatibilitas dengan server. Periksa persyaratan klien layanan itu sendiri, dan pilih mesin saja hanya ketika Anda berniat menyediakan pengelolaannya.