Split tunneling berbasis aplikasi vs berbasis tujuan: mana yang dipilih

Split tunneling berbasis aplikasi dan berbasis tujuan bukan dua pengaturan untuk pekerjaan yang sama. Yang satu bertanya proses mana yang mengirim paket; yang lain bertanya ke mana paket itu pergi. Aturan yang dibuat untuk pertanyaan pertama gagal diam-diam saat lalu lintas datang dari proses pembantu, dan aturan untuk pertanyaan kedua gagal saat nama host diresolusi ke alamat yang tidak pernah Anda daftarkan. Pilih objek yang sesuai dengan kebutuhan, lalu buktikan dengan dua paket uji: satu yang harus memakai tunnel dan satu yang tidak boleh.

Kedua aturan bekerja pada lapisan berbeda

Aturan aplikasi diterapkan di atas lapisan jaringan, terhadap identitas yang diberikan sistem operasi kepada pengirim. Di Android itu UID di balik paket, dan layanan VPN memutuskan per UID apakah lalu lintas masuk ke tunnel. Tidak ada yang ditanyakan tentang tujuan, jadi aplikasi yang dipilih dapat menjangkau apa pun dan tidak ada aplikasi lain yang dapat menjangkau jaringan internal.

Aturan tujuan diterapkan pada paket itu sendiri. Antarmuka tunnel memiliki sekumpulan prefiks, tabel routing mengirim lalu lintas yang cocok ke sana, dan proses pengirim tidak relevan. Itu sebabnya aturan tujuan mencakup layanan, printer, atau tugas batch yang tidak diingat siapa pun untuk didaftarkan, dan itu sebabnya aturan itu tidak dapat dinyatakan sebagai hanya program ini di platform yang kliennya tidak pernah melihat proses.

Aturan aplikasi cocok untuk klien seluler dan agen terkelola

Android menampilkan pilihan itu secara langsung: VpnService.Builder.addAllowedApplication() dan addDisallowedApplication() menerima nama paket dan menegakkan keputusan per UID, seperti dijelaskan di panduan pengembang VPN Android. iOS punya padanan melalui aturan VPN per aplikasi yang berbasis pengenal bundel, biasanya dikirim lewat profil MDM bukan diketik manual.

Klien desktop adalah titik lemah. Sebagian besar klien VPN Windows dan macOS merutekan berdasarkan tujuan dan tidak menawarkan pemilih per proses sama sekali, karena driver tunnel melihat paket, bukan proses. Jika rencana Anda bergantung pada men-tunnel satu aplikasi di laptop, periksa kemampuan nyata klien sebelum merancang di sekitarnya; mungkin Anda memilih antara daftar tujuan dan mesin kedua.

Akibat yang sering terlewat: Anda tidak dapat meniru aturan aplikasi dengan rute di platform tersebut. Menambahkan rute host untuk server aplikasi men-tunnel lalu lintas semua orang ke server itu, termasuk peramban dan pengupdate.

Aturan tujuan cocok untuk daftar subnet dan keterjangkauan situs

WireGuard membuat modelnya eksplisit. AllowedIPs adalah routing kunci-kripto: paket dalam yang tujuannya jatuh di dalam daftar peer dienkripsi ke peer itu, dan apa pun selainnya keluar tanpa enkripsi melalui jalur normal. Tidak ada proses untuk disebutkan dan tidak ada ambiguitas tentang apa yang tercakup.

OpenVPN mencapai titik yang sama melalui tabel rute yang didorong. route-nopull menghentikan server mendikte rute, setelah itu route 10.20.0.0 255.255.0.0 vpn_gateway di sisi klien mencakup tepat prefiks kantor. IPv6 adalah pernyataan terpisah di setiap klien ini, dan melupakannya adalah cara paling umum bocor di sekitar split IPv4 yang tampak benar.

Nama host bukan rute. Jika profil menyediakan kolom domain, perlakukan sebagai nama yang diresolusi klien sekali, bukan sebagai rentang alamat permanen; jaringan pengiriman konten dan penyeimbang beban akan memberi alamat berbeda besok.

Tempat kedua model patah: pembantu, layanan bersama, resolver

Proses pembantu mematahkan aturan aplikasi dengan cara yang tampak seperti kesalahan server. Pengupdate peramban, pelapor crash, layanan sinkronisasi yang berjalan sebagai SYSTEM, dan WebView yang tertanam di paket lain semuanya identitas terpisah, jadi men-tunnel peramban dapat meninggalkan permintaan sebenarnya di luar tunnel. Kebalikannya sama membingungkan: aplikasi yang dikecualikan tetapi memanggil pustaka bersama di dalam proses yang di-tunnel tetap lalu lintasnya lewat tunnel.

Aturan tujuan patah pada layanan bersama dan pada nama. Berbagi pakai file, printer, DNS internal, dan server lisensi semuanya hidup pada alamat, jadi tunnel satu aplikasi memberi peramban akses sementara drive yang dipetakan tetap mati. Perbedaan cakupan itu bukan bug pada kedua model, tetapi itulah sebabnya tunnel satu aplikasi begitu sering menghasilkan VPN menyala dan share hilang.

Resolver memotong keduanya. Jika klien menyetel server DNS internal tetapi sistem operasi memakai DNS melalui HTTPS ke resolver publik, jawabannya datang dari luar tunnel dan aturan tujuan mungkin tidak pernah cocok. Periksa resolver mana yang benar-benar menjawab sebelum menyimpulkan aturannya salah, dan pastikan di sisi klien apakah ia sama sekali memasang resolver tunnel. Split yang membiarkan DNS di luar tunnel tampak sempurna di tabel routing dan tetap gagal pada setiap nama internal.

Runbook: pilih, terapkan, verifikasi

Mulailah dari kebutuhan, bukan dari menu. Jika tujuannya hanya aplikasi ini yang boleh memakai tunnel, Anda perlu aturan aplikasi dan platform yang mendukungnya. Jika tujuannya jaringan ini dapat dijangkau melalui tunnel, Anda perlu prefiks. Jika jawabannya keduanya, terapkan sebagai dua kontrol terpisah dan catat mana yang memiliki kegagalan mana.

Terapkan bentuk paling sempit yang dapat Anda nyatakan, lalu verifikasi dengan bertanya kepada tabel routing, bukan ikon status klien:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Dua baris pertama menyebut antarmuka yang akan dipakai tujuan nyata; wg show mencetak daftar prefiks yang dikonfigurasi; di Windows, Find-NetRoute menjawab pertanyaan yang sama dengan yang akan dijawab tumpukan saat paket dikirim. Jika antarmukanya adalah tunnel, aturannya cocok.

Lalu uji paket kedua yang seharusnya dikecualikan, dari aplikasi berbeda, ke tujuan yang sama. Catat versi klien, jenis aturan, daftar prefiks atau paket, dan dua hasil yang diamati di tiket. Pasangan hasil itulah yang memberi tahu insinyur berikutnya apakah kebijakan salah konfigurasi atau lalu lintasnya memang tidak pernah termasuk.