Dua VPN iPhone sekaligus: mana yang membawa trafik Anda?

Dua aplikasi VPN sama-sama menampilkan Connected, dan anggapannya trafik kini melewati keduanya, satu di dalam yang lain. Biasanya tidak demikian. iOS memiliki model koeksistensi tertentu, dan itu bukan rantai. Satu kelas konfigurasi dibatasi pada satu instans yang diaktifkan, yang lain dapat berjalan di sampingnya, dan prioritas rute menentukan konflik. Dua sakelar menyala bukan dua lompatan. Modelnya terdokumentasi, artinya jalur dapat diprediksi alih-alih ditebak dari ikon.

Mitos: dua VPN terhubung adalah rantai

Rantai dua lompatan memerlukan transportasi luar yang terdefinisi, terowongan dalam yang terdefinisi, perutean titik akhir yang kompatibel, dan rencana untuk apa yang terjadi bila salah satunya gagal. Dua konfigurasi independen tidak menciptakan itu hanya dengan ada bersamaan. Prioritas rute bukan sama dengan enkapsulasi, dan menangnya satu konfigurasi dalam pencarian rute tidak mengatakan apa pun tentang apakah yang lain membawa paket yang dihasilkan.

Jika Anda memerlukan penyusunan bersarang, rancanglah sebagai penyusunan bersarang. Jangan menyimpulkannya dari dua indikator koneksi. Perbedaan itu menghemat banyak proses debug.

Model terdokumentasi di balik mitos itu

NETunnelProviderManager Apple menjelaskan konfigurasi VPN perusahaan biasa dan menyatakan bahwa hanya satu dari jenis itu yang dapat diaktifkan pada satu waktu. Referensi yang sama memungkinkan Personal VPN tetap aktif dan terhubung di sampingnya, dan memberikan prioritas pada rute perusahaan di tempat keduanya tumpang tindih.

Personal VPN di sini adalah istilah API untuk implementasi IPsec atau IKEv2 bawaan yang dikelola melalui NEVPNManager. NETunnelProviderManager adalah model penyedia terowongan. Aplikasi konsumen dapat menggunakan model penyedia, jadi nama produk yang mengandung personal tidak mengklasifikasikannya.

Apple mendokumentasikan satu kombinasi yang diizinkan, dan izin tidak memberi tahu Anda bahwa profil dua vendor kompatibel, jadi tanyakan kepada setiap vendor pasangan mana yang didukung. Jenis konfigurasi, rute, dan kebijakan mereka tetap menentukan hasilnya.

Mitos: VPN pribadi mendapat trafik penjelajahan

Profil kerja yang mengklaim setiap tujuan akan memenangkan pencarian rute untuk penjelajahan publik juga, jadi jalur keluar pribadi tidak membawa apa pun darinya. Menurut prioritas yang didokumentasikan, rute perusahaan menang di tempat keduanya bertentangan, jadi penjelajahan publik tidak otomatis mengambil jalur keluar pribadi hanya karena aplikasi itu juga melaporkan terhubung. Konfigurasi kerja yang lebih sempit dapat mengubah gambaran perutean, tetapi klien organisasi tetap dapat memberlakukan persyaratan DNS, pemblokiran, atau perangkat. Dapatkan pengaturan yang didukung dari pemiliknya alih-alih mengedit persyaratan itu secara lokal.

Konfigurasi terkelola per aplikasi memiliki cakupannya sendiri. Jangan memperluas aturan tingkat perangkat ke setiap penerapan terkelola.

Catat kedua aliran sebelum menguji: nama dan rentang privat layanan kerja, dan permintaan penjelajahan publik yang baru. Keduanya sah, dan keduanya memerlukan pemeriksaan berbeda.

Prioritas rute dengan profil kerja terowongan terpisah

Profil kerja dengan terowongan terpisah mengklaim prefiks privat dan akhiran DNS internal yang dicantumkannya, dan rute tersebut memenangkan setiap pencarian yang cocok dengannya. Tujuan publik yang tidak cocok dengan rute perusahaan mana pun jatuh ke tautan fisik kecuali VPN pribadi mengklaimnya lebih dulu. Aturan prioritas hanya menentukan kecocokan yang tumpang tindih, itulah sebabnya kedua profil harus dibaca sebagai tabel rute, bukan sebagai ikon.

Tulis pasangan itu dalam dua baris dan sebutkan pemenang yang diharapkan untuk masing-masing: nama host kerja yang mengarah ke 10.x atau 172.16.x seharusnya keluar melalui terowongan perusahaan, dan alamat publik tanpa prefiks yang cocok seharusnya mengambil rute default yang tersisa. Jika kedua baris menyebutkan jalur keluar yang sama, pemisahan itu tidak melakukan apa yang dijelaskan dokumentasi.

Catat dua aliran dan uji masing-masing

Untuk setiap aliran, catat konfigurasi yang disetujui mana yang harus membawanya dan resolver mana yang harus menerima setiap jenis nama. Lalu verifikasi dengan permintaan baru, bukan dengan halaman kerja yang di-cache atau hasil IP lama.

Hentikan satu konfigurasi dan ulangi kedua aliran. Perilaku kegagalan adalah bagian dari desain, dan itulah bagian yang diperhatikan pengguna. Ketika kedua penyedia tidak dapat mendukung kombinasi itu, tetapkan satu konfigurasi yang disetujui dan dokumentasikan aliran mana yang dibawanya, atau beralih ke desain terowongan tunggal terkelola. Dokumentasi NETunnelProviderManager adalah sumber aturan koeksistensi.