Split tunneling berasaskan aplikasi vs berasaskan destinasi: mana untuk dipilih
Satu peraturan mengikut proses, satu lagi mengikut alamat. Pilih mengikut apa yang perlu anda kawal, kemudian uji proses pembantu dan aplikasi kedua pada subnet yang sama.
Split tunneling berasaskan aplikasi dan berasaskan destinasi bukan dua tetapan untuk kerja yang sama. Satu bertanya proses mana yang menghantar paket; satu lagi bertanya ke mana paket itu pergi. Peraturan yang dibina untuk soalan pertama gagal secara senyap apabila trafik datang daripada proses pembantu, dan peraturan untuk soalan kedua gagal apabila nama hos diselesaikan kepada alamat yang tidak pernah anda senaraikan. Pilih objek yang sepadan dengan keperluan, kemudian buktikannya dengan dua paket ujian: satu yang mesti menggunakan terowong dan satu yang tidak boleh.
Dua peraturan bertindak pada lapisan berbeza
Peraturan aplikasi dikuatkuasakan di atas lapisan rangkaian, terhadap identiti yang diberikan sistem pengendalian kepada penghantar. Pada Android itu UID di sebalik pakej, dan perkhidmatan VPN memutuskan bagi setiap UID sama ada trafik masuk ke terowong. Tiada apa-apa ditanya tentang destinasi, jadi aplikasi yang dipilih boleh mencapai apa sahaja dan tiada aplikasi lain boleh mencapai rangkaian dalaman.
Peraturan destinasi dikuatkuasakan pada paket itu sendiri. Antara muka terowong memiliki satu set awalan, jadual penghalaan menghantar trafik yang sepadan ke dalamnya, dan proses penghantar tidak relevan. Itulah sebabnya peraturan destinasi meliputi perkhidmatan, pencetak atau kerja kelompok yang tiada siapa ingat untuk menyenaraikan, dan itulah sebabnya ia tidak boleh dinyatakan sebagai program ini sahaja pada platform yang kliennya tidak pernah melihat proses.
Peraturan aplikasi sesuai untuk klien mudah alih dan agen terurus
Android mendedahkan pilihan itu secara langsung: VpnService.Builder.addAllowedApplication() dan addDisallowedApplication() mengambil nama pakej dan menguatkuasakan keputusan bagi setiap UID, seperti yang diterangkan dalam panduan pembangun VPN Android. iOS mempunyai persamaan melalui peraturan VPN setiap aplikasi yang berkunci pada pengecam bundle, biasanya dihantar melalui profil MDM dan bukan ditaip dengan tangan.
Klien desktop ialah titik lemah. Kebanyakan klien VPN Windows dan macOS menghala mengikut destinasi dan tidak menawarkan pemilih setiap proses sama sekali, kerana pemacu terowong melihat paket, bukan proses. Jika rancangan anda bergantung pada menyalurkan satu aplikasi melalui terowong pada komputer riba, semak keupayaan sebenar klien sebelum mereka bentuk mengenainya; mungkin anda memilih antara senarai destinasi dan mesin kedua.
Akibat yang orang terlepas: anda tidak boleh meniru peraturan aplikasi dengan laluan pada platform tersebut. Menambah laluan hos untuk pelayan aplikasi menyalurkan trafik semua orang ke pelayan itu, termasuk pelayar dan pengemas kini.
Peraturan destinasi sesuai untuk senarai subnet dan ketersampaian tapak
WireGuard menjadikan model itu eksplisit. AllowedIPs ialah penghalaan kunci kripto: paket dalaman yang destinasinya jatuh dalam senarai rakan disulitkan kepada rakan itu, dan segala-galanya keluar tanpa penyulitan melalui laluan biasa. Tiada proses untuk dinamakan dan tiada kekaburan tentang apa yang disertakan.
OpenVPN sampai ke tempat yang sama melalui jadual laluan yang ditolak. route-nopull menghentikan pelayan daripada menentukan laluan, selepas itu route 10.20.0.0 255.255.0.0 vpn_gateway di sisi klien meliputi tepat awalan pejabat. IPv6 ialah pernyataan berasingan dalam setiap klien ini, dan melupakannya ialah cara paling biasa untuk bocor di sekeliling pemisahan IPv4 yang kelihatan betul.
Nama hos bukan laluan. Jika profil menawarkan medan domain, anggap ia sebagai nama yang klien selesaikan sekali, bukan julat alamat kekal; rangkaian penghantaran kandungan dan pengimbang beban akan memberikan alamat berbeza esok.
Di mana kedua-dua model pecah: pembantu, perkhidmatan dikongsi, penyelesai
Proses pembantu memecahkan peraturan aplikasi dengan cara yang kelihatan seperti kerosakan pelayan. Pengemas kini pelayar, pelapor ranap, perkhidmatan penyegerakan yang berjalan sebagai SYSTEM dan WebView yang tertanam dalam pakej lain semuanya identiti berasingan, jadi menyalurkan pelayar melalui terowong boleh meninggalkan permintaan sebenar di luar terowong. Sebaliknya juga sama mengelirukan: aplikasi yang dikecualikan tetapi memanggil pustaka dikongsi di dalam proses yang disalurkan masih mempunyai trafiknya melalui terowong.
Peraturan destinasi pecah pada perkhidmatan dikongsi dan pada nama. Perkongsian fail, pencetak, DNS dalaman dan pelayan pelesenan semuanya hidup pada alamat, jadi terowong satu aplikasi memberi pelayar akses manakala pemacu yang dipetakan kekal mati. Perbezaan liputan itu bukan pepijat dalam mana-mana model, tetapi itulah sebabnya terowong satu aplikasi begitu kerap menghasilkan VPN hidup dan perkongsian telah hilang.
Penyelesai memotong kedua-duanya. Jika klien menetapkan pelayan DNS dalaman tetapi sistem pengendalian menggunakan DNS melalui HTTPS ke penyelesai awam, jawapan datang dari luar terowong dan peraturan destinasi mungkin tidak pernah sepadan. Semak penyelesai mana yang benar-benar menjawab sebelum membuat kesimpulan peraturan itu salah, dan sahkan di sisi klien sama ada ia memasang penyelesai terowong langsung. Pemisahan yang membiarkan DNS di luar terowong kelihatan sempurna dalam jadual penghalaan dan masih gagal pada setiap nama dalaman.
Prosedur: pilih, gunakan, sahkan
Mulakan daripada keperluan, bukan menu. Jika matlamatnya hanya aplikasi ini boleh menggunakan terowong, anda memerlukan peraturan aplikasi dan platform yang menyokongnya. Jika matlamatnya rangkaian ini boleh dicapai melalui terowong, anda memerlukan awalan. Jika jawapannya kedua-duanya, laksanakan sebagai dua kawalan berasingan dan catatkan yang mana memiliki kegagalan yang mana.
Gunakan bentuk paling sempit yang boleh anda nyatakan, kemudian sahkan dengan bertanya kepada jadual penghalaan dan bukannya 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 menamakan antara muka yang akan digunakan oleh destinasi sebenar; wg show mencetak senarai awalan yang dikonfigurasikan; pada Windows, Find-NetRoute menjawab soalan yang sama dengan yang akan dijawab oleh tindanan apabila paket dihantar. Jika antara muka itu terowong, peraturan itu sepadan.
Kemudian uji paket kedua yang sepatutnya dikecualikan, daripada aplikasi berbeza, ke destinasi yang sama. Catatkan versi klien, jenis peraturan, senarai awalan atau pakej dan dua hasil yang diperhatikan dalam tiket. Pasangan hasil itulah yang memberitahu jurutera seterusnya sama ada dasar itu salah dikonfigurasikan atau trafik itu tidak pernah menjadi miliknya.