Bagaimana MOBIKE menjaga VPN IKEv2 tetap hidup saat jaringan berubah
MOBIKE memperbarui koneksi IKEv2 yang didukung saat perangkat berpindah jaringan. Perutean, penyaringan, dan pemulihan sesi aplikasi tetap harus bekerja.
Ponsel meninggalkan Wi-Fi dan bergabung ke jaringan seluler, laptop berpindah dari Ethernet ke hotspot, dan terowongan IKEv2 entah bertahan atau tidak. MOBIKE adalah ekstensi yang membuatnya bertahan, dengan memberi tahu ujung jauh bahwa alamat sumber telah berubah alih-alih memulai dari awal. Yang tidak dilakukannya adalah menjaga setiap aplikasi tetap hidup selama perubahan. Itu dua klaim, dan yang kedua adalah yang biasanya dimaksud orang.
Telusuri transisi secara bertahap, karena setiap tahap gagal dengan cara berbeda.
Apa yang sebenarnya diubah pembaruan
Selama asosiasi keamanan masih valid, penginisiasi mempelajari alamat barunya dan mengirim pembaruan ke penanggap, yang kemudian menggunakan alamat itu untuk asosiasi yang sama. Parameter keamanan tidak dinegosiasikan ulang dari awal. Itulah seluruh manfaatnya: tidak ada putaran autentikasi baru, tidak ada pertukaran kunci baru, tidak ada permintaan kepada pengguna. Ini juga berarti keadaan yang bertahan masih milik sesi lama.
MOBIKE juga dapat memindahkan lalu lintas ke enkapsulasi UDP, itulah sebabnya terowongan yang berfungsi kadang mulai memakai port 4500 setelah perubahan jaringan. Transisi itu sendiri tidak membuktikan bahwa NAT terdeteksi, meskipun keduanya sering muncul bersamaan.
Apakah profil Anda benar-benar mengaktifkannya
Kedua pihak harus mendukung ekstensi, dan penerapan harus mengaktifkannya. Di strongSwan perilakunya dapat dikonfigurasi per koneksi, dan perubahan antarmuka atau rute dapat memicu pencarian jalur dan pembaruan bila diperlukan. Periksa pengaturan sebenarnya koneksi alih-alih menganggap setiap profil IKEv2 menyalakannya. Profil yang disalin dari panduan yang lebih tua dari fitur ini adalah sumber umum masalah ini.
Keadaan yang dinegosiasikan di kedua ujung adalah otoritas, bukan dokumentasi keluarga produk.
Telusuri transisi secara bertahap
Catat keadaan aplikasi sebelum berpindah jaringan. Lalu berpindah, dan catat keadaan klien dan server sesudahnya. Alamat yang hilang, rekan yang tidak terjangkau, dan aplikasi yang harus menyambung ulang sesinya sendiri adalah tiga hasil berbeda. Hanya dua yang pertama termasuk lapisan VPN; yang ketiga termasuk protokol apa pun yang dibicarakan aplikasi.
Bandingkan pergantian jaringan dengan uji diam, agar Anda tahu peristiwa mana yang memicu masalah. Pengukuran throughput pada jaringan akhir tidak dapat mereproduksi transisi. Ia mengukur tujuan, bukan perjalanan.
Pisahkan lapisan kegagalan
Sesi TCP berumur panjang dapat gagal karena alasan di luar pertukaran IKEv2. Jaringan baru dapat menyaring, menyelesaikan, atau merutekan secara berbeda. Alamat terowongan mungkin tidak berubah sama sekali sementara jalur di bawahnya berubah. Itulah sebabnya menyambung ulang aplikasi dapat memperbaiki sesuatu yang tidak pernah dirusak VPN.
Pertahankan kebijakan pemblokiran saat Anda memulihkan juga.
Mobilitas otomatis dan aturan yang mencegah lalu lintas langsung adalah kontrol berbeda, dan menonaktifkan yang kedua agar yang pertama berfungsi adalah pertukaran buruk. Jika pembaruan mobilitas gagal, pemblokiran harus bertahan alih-alih membiarkan lalu lintas bocor di sekitar terowongan.
Apa yang dicatat saat berulang
Simpan stempel waktu dan kedua nilai alamat dari kedua sisi. Catatan itu menunjukkan apakah pembaruan selesai sebelum aplikasi kehilangan kontak, yang merupakan perbedaan antara bug mobilitas dan waktu tunggu aplikasi. Lalu bandingkan arah pergantian: meninggalkan Wi-Fi untuk seluler tidak simetris dengan sebaliknya. Satu arah bisa berhasil sementara yang lain gagal.
Asimetri itu cukup umum untuk menjadi hal pertama yang diuji.
Dengan catatan di tangan, insiden berhenti menjadi ikon terputus lain dan menjadi satu peristiwa dalam urutan dengan pemilik yang diketahui. Itu semua yang bisa dijanjikan sebuah panduan dengan jujur.