VPN Mac, filter konten, atau Private Relay: mana yang aktif

Mac Anda bisa memiliki tunnel VPN, filter konten, dan iCloud Private Relay terpasang sekaligus, dan tidak satu pun memberi tahu mana yang membentuk suatu koneksi. Panel pengaturan tampak serupa, ikonnya tampak serupa, dan hampir setiap vendor menyebut produknya keamanan jaringan. Tiga fakta memisahkan ketiganya: apakah lalu lintas keluar lewat titik akhir jauh yang bisa Anda sebutkan, apakah mesin kebijakan mengambil keputusan izinkan-atau-jatuhkan pada alur individual, dan apakah perlindungannya berhenti di Safari. Rapikan ketiganya dan sebagian besar pertanyaan apakah-VPN-saya-aktif terjawab sendiri.

Tiga syarat yang mengenali komponennya

Syarat pertama adalah jalan keluar. Penyedia tunnel menyerahkan paket ke gateway jauh, sehingga alamat publik Anda berubah dan, jika profil mengatakannya, host di balik gateway itu menjadi terjangkau. Jika alamatnya tidak pernah berubah dan tidak ada subnet privat yang terbuka, Anda tidak sedang melihat tunnel yang berfungsi, apa pun kata bilah menu.

Syarat kedua adalah keputusan. Filter konten menilai alur dan mengembalikan izinkan atau jatuhkan. Ia dapat menegakkan blokir kategori, aturan per aplikasi, atau kebijakan yang dikirim pemberi kerja, dan ia dapat mencatat putusannya. Yang tidak bisa dilakukannya sendiri adalah memberi lalu lintas tempat untuk pergi.

Syarat ketiga adalah cakupan. Private Relay melindungi sebagian penjelajahan yang terdefinisi, bukan seluruh perangkat, dan tugasnya memisahkan siapa Anda dari apa yang Anda kunjungi, bukan menempatkan Anda di jaringan lain.

Sejajarkan ketiganya dan batasnya sulit terlewat:

Filter konten adalah mesin kebijakan, bukan jalan keluar

Di macOS filter hadir sebagai Network Extension yang dibangun di atas kelas penyedia data filter Apple, NEFilterDataProvider. Dalam penerapan terkelola, MDM mendorongnya, ia dipasang sebagai ekstensi sistem dan disetujui sekali di System Settings > General > Login Items and Extensions. Sejak itu ia melihat alur TCP, dan pada sebagian konfigurasi juga UDP, lalu mengembalikan putusan untuk masing-masing.

Cara gagalnya itulah yang membingungkan orang. Filter yang menjatuhkan alur menghasilkan timeout, jabat tangan TLS yang tersendat, atau reset, yang tampak persis seperti tunnel yang sudah naik tetapi tidak bisa melewatkan lalu lintas. Alamat publik tidak pernah berubah, karena tidak pernah ada jalan keluar yang mengubahnya.

Klien komersial sering menggabungkan kedua peran. Satu pemasang membawa penyedia tunnel dan filter, filter melakukan pemblokiran, dan tunnel melakukan perutean. Jadi nama aplikasi tidak memberi tahu apa pun tentang komponen mana yang menolak koneksi. Periksa daftar ekstensi, lalu layanan yang terhubung, lalu log klien, dalam urutan itu.

Private Relay mencakup Safari, bukan seluruh mesin

Private Relay mengirim penjelajahan yang dicakupnya melalui dua relai yang dijalankan pihak terpisah, sehingga tidak ada satu operator pun yang memegang identitas dan tujuan Anda sekaligus. Itu desain privasi, bukan tunnel: tidak ada gateway yang bisa dimasuki, tidak ada subnet privat, dan tidak ada cara menyematkan alamat keluar di negara yang Anda pilih.

Cakupannya sengaja sempit, mencakup penjelajahan Safari bersama kueri DNS dan pemuatan HTTP tidak aman yang menyertainya. Sesi terminal, klien surel, aplikasi obrolan, dan peluncur gim berada di luarnya. Jika pemeriksaan di Terminal masih menunjukkan alamat jaringan akses Anda sementara Safari menunjukkan alamat relai, itulah hasil yang diharapkan, bukan pemasangan yang rusak.

Ketersediaannya bersyarat. Ia memerlukan paket iCloud+, tidak ditawarkan di setiap wilayah, dan jaringan terkelola dapat memblokir akses relai, dan dalam hal itu Safari kembali ke koneksi langsung. Ikhtisar Private Relay dari Apple adalah rujukan cakupan saat ini. Ketika profil VPN terhubung dan membawa lalu lintas itu, relai tidak ditumpuk di atasnya; profil yang menentukan jalurnya.

Baca bukti dalam urutan yang benar

Mulai dari status layanan, karena itu sinyal termurah. scutil --nc list mencetak layanan VPN yang dikonfigurasi dan apakah masing-masing terhubung. Profil bisa duduk di sana bertahun-tahun tanpa pernah terhubung, dan orang biasa menghitungnya sebagai tunnel.

Lalu lihat antarmuka dan rute. ifconfig menunjukkan antarmuka utun, tetapi keberadaannya sendiri tidak membuktikan banyak, karena macOS memakai utun untuk beberapa keperluan di luar VPN. Yang penting adalah apakah rute bawaan mengarah ke salah satunya, yang dilaporkan route -n get default.

Untuk resolusi nama, scutil --dns mendaftar resolver yang benar-benar akan dipakai sistem, dan penyedia proksi DNS muncul di sana. Membandingkan dig +short example.com dengan dig +short example.com @1.1.1.1 memisahkan resolver yang menjawab dari resolver yang dicegat.

Aktivitas ekstensi sampai ke log terpadu: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Anda mencari ekstensi mana yang dimulai dan apakah filter melaporkan putusan atas alur yang Anda pedulikan, bukan baris untuk dihafal.

Persempit gejalanya sebelum menonaktifkan apa pun

Klasifikasikan dulu kegagalannya. Nama yang tidak ter-resolve, koneksi yang ditolak seketika, dan koneksi yang menggantung sampai timeout adalah tiga pengamatan berbeda dengan tiga pemilik berbeda. Resolusi menunjuk ke resolver atau proksi DNS. Penolakan seketika menunjuk ke aturan filter. Kesunyian biasanya menunjuk ke perutean, atau ke tunnel yang naik tetapi tidak meneruskan.

Di Mac terkelola, anggap filter milik organisasi. Menonaktifkannya untuk menguji VPN menghapus komponen yang justru ingin Anda amati, dan MDM sering memulihkannya pada pemeriksaan berikutnya. Tanyakan nama kebijakan kepada administrator sebelum mengubah apa pun, dan uji dengan aplikasi tertentu yang gagal, bukan seluruh sistem.

Satu jebakan lagi: mematikan Private Relay untuk menguji VPN tidak mengatakan apa pun tentang lalu lintas asing, karena relai tidak pernah mencakup lalu lintas itu. Setiap lapisan harus diuji pada aplikasi yang benar-benar dikendalikannya.

Telusuri daftar ini dan berhenti pada butir pertama yang gagal:

• Apakah scutil --nc list menunjukkan layanan yang Anda harapkan sebagai terhubung?
• Apakah alamat publik yang terlihat dari Terminal berbeda dari alamat yang diberikan jaringan akses Anda?
• Apakah ada ekstensi filter terpasang, dan apakah ia mencatat putusan untuk alur yang gagal?
• Apakah kegagalannya hanya di Safari? Jika ya, periksa cakupan relai sebelum menyalahkan tunnel.

Jika keempatnya lolos dan aplikasi tetap gagal, masalahnya ada di atas lapisan jaringan: pengaturan proksi, kepercayaan sertifikat, atau daftar izin tingkat aplikasi.