Mode SOCKS NetGuard mencakup TCP, bukan setiap protokol

NetGuard menempati antarmuka VPN Android untuk memfilter lalu lintas, dan dapat menyerahkan koneksi yang didukung ke titik akhir SOCKS. Kedua fakta ini sering dibaca sebagai “ponsel berada di VPN”, sebuah kesimpulan yang tidak didukung mekanismenya. Filter melihat paket; proksi hanya melihat koneksi yang benar-benar diserahkan kepadanya. Di antara kedua pernyataan itu terdapat seluruh pertanyaan tentang cakupan.

FAQ proyek asal mendokumentasikan batasan satu layanan dan opsi SOCKS. Keberadaan opsi itu bukan bukti bahwa setiap paket yang diizinkan memakainya, dan dari celah itulah muncul pertanyaan cakupan.

Dua jalur penerusan di dalam satu aplikasi

Sisi TCP implementasi memuat penanganan koneksi SOCKS, sehingga koneksi TCP yang diizinkan dapat dinegosiasikan dengan proksi dan dibawa melaluinya. Sisi UDP memiliki jalur soket terpisah, dan penanganan pengiriman serta penerimaannya tidak bergantung pada negosiasi TCP tersebut. Karena itu, datagram yang diizinkan filter dapat mencapai jaringan biasa tanpa pernah melewati proksi. Tidak ada yang merupakan cacat aplikasi dalam hal ini; itu sekadar yang diimplementasikan kedua jalur.

Perbedaan ini punya konsekuensi yang sering salah dijelaskan orang ke dua arah. Menyebut setiap paket UDP sebagai kebocoran mengabaikan aturan pemblokiran, karena datagram yang ditolak tidak pernah keluar. Menyebut seluruh pengaturan sebagai VPN mengabaikan jalur langsung yang diizinkan, karena sebagian lalu lintas memang keluar tanpa proksi. Yang Anda miliki adalah perangkat tersaring dengan proksi sebagian, dan deskripsi jujurnya adalah matriks, bukan label.

Mengiklankan UDP bukan menerapkannya

Server SOCKS yang mengklaim dukungan UDP tidak menambahkan penanganan sisi klien yang sesuai ke aplikasi di ponsel Anda. Fitur teoretis protokol dan perilaku build yang terpasang adalah subjek berbeda, dan hanya yang kedua menggambarkan lalu lintas Anda.

Periksa versi dan konfigurasi yang benar-benar Anda jalankan, lalu uji aliran datagram yang tidak berbahaya dan amati apakah muncul di proksi. Segala hal lain adalah inferensi dari daftar fitur, dan daftar fitur menggambarkan niat, bukan jalur kode.

DNS adalah jalur ketiga, bukan detail

Resolusi nama menambahkan cabangnya sendiri ke matriks. Penerus DNS lokal, kueri UDP biasa, nama host tujuan yang diresolusi proksi itu sendiri, dan resolver terenkripsi di peramban adalah empat pengaturan berbeda. Semuanya berbeda dalam siapa yang melihat kueri dan jalur jaringan mana yang membawanya, dan mencampurnya menghasilkan uji yang tidak membuktikan apa pun tentang yang lain.

Putuskan dengan sengaja mana yang Anda inginkan. Jika persyaratannya adalah nama diresolusi melalui terowongan, pengaturan peramban saja tidak akan mewujudkannya, dan proksi yang meresolusi nama host sendiri hanya mengubah jawaban untuk koneksi yang benar-benar ditanganinya.

Transportasi proksi tidak otomatis privat

SOCKS biasa bukan tautan terenkripsi dari ponsel ke proksi. Jika titik akhir dicapai melalui jalur terlindungi lain, sebutkan jalur itu dan kebijakan kegagalannya, karena mundur ke jaringan terbuka mengubah pengaturan privat menjadi publik tanpa peringatan. Autentikasi proksi itu sendiri juga penting: pendengar terbuka pada perangkat bersama adalah layanan yang tidak dipertanggungjawabkan siapa pun.

Pengaturan antarprofil layak mendapat pemeriksaan yang sama. VPN profil kerja hanya melindungi lalu lintas yang memakai jalurnya, dan keberadaan bersamaan tembok api profil pribadi dengan terowongan kerja tidak membuktikan bahwa koneksi lanjutan tembok api itu mencapai terowongan tersebut. Verifikasi keterjangkauan dan autentikasi daripada menganggap kedua profil bekerja sama.

Audit cakupan dengan matriks, bukan dengan memuat halaman

Untuk evaluasi yang diizinkan, pilih contoh tidak berbahaya yang mewakili setiap kelas yang Anda pedulikan: TCP yang diperlukan, UDP yang diizinkan, dan DNS di kedua keluarga alamat. Untuk masing-masing, catat apakah diproksikan, diblokir, atau dikirim langsung. Satu tabel itulah hasilnya, dan jauh lebih berguna daripada tangkapan layar halaman yang termuat.

Jika persyaratannya adalah seluruh lalu lintas aplikasi terpilih harus melewati terowongan jarak jauh, pilih implementasi yang secara eksplisit mendukung penyaringan dan terowongan gabungan. Komposisi proksi hanya-TCP tetap berguna untuk tugas yang lebih sempit, asalkan lalu lintas lain ditangani dengan sengaja, bukan dilupakan.