iPhone Always On VPN: dua terowongan bisa berbagi satu IP virtual

Pada iPhone terawasi dengan profil Always On terkelola, ponsel memegang terowongan untuk setiap antarmuka IP aktif, sehingga seluler dan Wi-Fi masing-masing mendapatkannya. Server lalu menampilkan dua asosiasi keamanan IKE untuk satu perangkat, sering berbagi satu alamat virtual, dan dorongan pertama adalah menyebutnya loop rekey dan mulai mengubah timer. Dorongan itu biasanya keliru. Telusuri langkah di bawah ini dalam urutan bukti muncul di server, dan biarkan pengaturan ponsel sampai server memberi tahu kasus mana yang Anda hadapi.

Mulailah dari dua baris yang sudah dimiliki server

Daftar asosiasi dengan swanctl --list-sas dan baca empat bidang pada kedua entri: alamat jarak jauh, identitas terautentikasi, IP virtual yang diberikan, dan waktu pembuatan. Dua alamat luar berbeda dengan satu identitas dan satu IP virtual adalah bentuk yang memulai pertanyaan ini, dan layak dicatat sebelum perubahan apa pun. Lalu periksa asosiasi anak yang melekat pada masing-masing, karena pemilih lalu lintas menentukan apakah pencarian tujuan bisa membedakan kedua terowongan. Pasangan yang muncul dan hilang dalam hitungan detik adalah hewan yang berbeda dari pasangan yang keduanya hidup berjam-jam.

Urutkan daftar berdasarkan waktu pembuatan sebelum menarik kesimpulan. Kedekatan dalam keluaran tidak berarti apa-apa, dan daftar berbentuk tabel justru mengundang kesalahan itu.

Tentukan tumpang tindih mana yang Anda lihat

Rekey IKEv2 dan reautentikasi make-before-break sengaja menciptakan tumpang tindih singkat, dengan membangun asosiasi baru sebelum menghapus yang lama. Stempel waktu menyelesaikan kasusnya, karena SA lama yang hilang satu atau dua detik setelah yang baru muncul adalah pembaruan yang menjalankan tugasnya. Terowongan antarmuka independen tidak pernah tampak seperti itu, karena masing-masing bertahan selama antarmukanya aktif, dan menghapus satu tidak mengikuti dari pembuatan yang lain.

Perilaku Always On terkelola Apple bersifat per antarmuka, itulah sebabnya perangkat terawasi bisa tampak sah lebih sibuk daripada profil yang dikonfigurasi manual. Sakelar sambung otomatis aplikasi penyedia tidak menyiratkan hal yang sama, dan aturan on-demand biasa juga tidak. Ikhtisar penerapan Apple menjelaskan model per antarmuka; bandingkan kedua baris Anda dengannya sebelum menganggap ada loop. Kedua bentuk juga mengambil dari kumpulan server yang sama, jadi tumpang tindih adalah satu-satunya sinyal awal Anda.

Lihat mengapa satu alamat virtual untuk dua terowongan merusak balasan

Balasan ke ponsel dialamatkan ke alamat internal, dan kernel memilih terowongan keluar berdasarkan tujuan dan kebijakan, bukan berdasarkan antarmuka yang dipakai ponsel. Dua asosiasi bersamaan yang memegang IP virtual sama dengan kebijakan yang bertepatan membuat keputusan perutean tidak punya cara mengatakan balasan milik sesi mana. Sebagian balasan mengambil terowongan yang salah, dan ponsel menunjukkan koneksi yang bekerja satu arah atau mati saat Wi-Fi menyala. Dua keluaran perintah membuktikan keadaan: swanctl --list-sas menunjukkan IP virtual yang sama pada kedua SA, dan ip xfrm policy menunjukkan dua pemilih identik.

Pasangan keluaran itulah yang Anda tempelkan ke catatan perubahan. Tidak ada satu pun yang meyakinkan sendiri, karena masing-masing bisa tampak masuk akal secara terpisah.

Ini pengalamatan dan kebijakan sisi server, bukan perilaku buruk ponsel, dan tidak ada pengaturan klien yang memisahkan dua alamat internal identik. Kumpulan memberikan nilai yang sama dua kali dan pemasang kebijakan menerimanya. Baca hasilnya dari sisi server sebelum menyalahkan klien.

Ubah kumpulan atau model konkurensi, bukan timer rekey

Dalam konfigurasi swanctl, keunikan adalah kebijakan eksplisit pada koneksi: unique = replace menghapus koneksi lama saat koneksi baru terbentuk, dan unique = keep menolak pendatang baru. Kedua nilai berlaku saat koneksi disiapkan, bukan pada SA anak di dalamnya.

connections {
  ios-alwayson {
    unique = replace
  }
}

Tidak ada nilai yang netral bagi klien per antarmuka. keep memulihkan layar status yang rapi dengan menolak terowongan kedua dan merusak desain terkelola, sedangkan replace merobohkan terowongan lama dan merupakan kompromi yang sama ke arah lain. Jika kedua terowongan benar-benar dibutuhkan, backend kumpulan harus menerbitkan sewa berbeda untuk satu identitas, dan kunci sewanya harus membedakan permintaan. Tabel identitas-ke-alamat statis akan dengan senang hati mengembalikan alamat yang sama dua kali dan mereproduksi masalah awal dengan lebih banyak konfigurasi. Periksa bagaimana backend mengunci sewa sebelum menambahkan pemetaan statis kedua.

Uji transisi yang benar-benar Anda terapkan

Keluar dari jangkauan Wi-Fi dengan sesi aktif, lalu masuk lagi, dan periksa bahwa balasan tiba di kedua arah. Lakukan dua kali, karena transisi kedua adalah tempat kebijakan usang biasanya muncul. Uji dengan layanan yang menjawab pada koneksi yang Anda buka, dan ulangi keluar saat terowongan membawa lalu lintas alih-alih diam menganggur. Ponsel yang bisa mengirim tetapi tidak menerima tampak sehat di log handshake dan rusak di peramban.

Layar status yang menyusut menjadi satu baris bukan bukti desain yang bekerja, hanya bukti bahwa satu terowongan hilang. Kedua arah harus bekerja sebelum transisi lolos. Catat apa yang Anda amati, bersama dua keluaran pemeriksaan tumpang tindih, agar insinyur berikutnya bisa membandingkan alih-alih mengulang jalan-jalan.