VPN tersambung ulang saat menyetir: pergantian radio atau pergantian IP?
Perpindahan antar menara bisa membiarkan jalur IP tetap utuh. Bandingkan klien yang memindahkan terowongan dengan yang membangunnya ulang, dan bacalah peristiwa jaringan, bukan perjalanannya.
Panggilan terputus saat Anda melewati pinggiran kota, dan ikon VPN hilang pada saat yang sama. Menggoda untuk mencatatnya sebagai “pergantian menara membunuh terowongan”. Dua hal berbeda terjadi, dan hanya satu di antaranya soal menara. Perpindahan radio bisa membiarkan alamat IP, rute bawaan, dan sesi Anda sepenuhnya utuh, sementara perubahan alamat yang sungguhan akan memutus terowongan apa pun yang tidak bisa ikut berpindah. Membandingkan bagaimana klien menangani kasus kedua itulah latihan yang berguna, karena memberi tahu apakah Anda melihat perilaku yang dirancang atau bug.
Pergantian menara belum tentu pergantian alamat
Jaringan seluler menjaga sesi paket tetap hidup selama perpindahan selama jangkar mobilitas operator tetap sama. Tautan radio berubah, terowongan tidak menyadarinya, dan tidak boleh ada penyambungan ulang di log mana pun. Ini kasus biasa untuk pergerakan di dalam kota.
Yang benar-benar mengubah alamat adalah perpindahan antar jangkar, peralihan dari Wi-Fi ke seluler, atau pembentukan ulang terowongan di sisi operator setelah jeda panjang. Peristiwa itu mengganti alamat sumber yang dibawa paket Anda, dan rekan VPN melihat rekan yang telah berpindah.
Konsekuensi praktisnya, pergerakan bukanlah bukti. Perangkat yang menempuh empat puluh kilometer bisa saja mempertahankan satu alamat sepanjang jalan, dan perangkat yang diam bisa saja berganti alamat dua kali karena jaringan memutuskan begitu. Mencatat peristiwanya adalah satu-satunya cara membedakan keduanya.
Dua rancangan: pindahkan terowongan atau bangun ulang
Klien berbeda dalam seberapa peduli mereka bahwa sumber luar berubah. Sebagian mengikat terowongan ke alamat tempat ia dibangun dan menuntut pembentukan ulang penuh. Yang lain mengautentikasi setiap paket secara mandiri dan hanya memperbarui ke mana balasan dikirim.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
Baris atas menjelaskan banyak laporan yang membingungkan. WireGuard tidak punya sesi yang bisa diputus: setiap paket membawa indeks rekan dan diautentikasi, jadi paket sah yang datang dari alamat baru menurut definisi berasal dari rekan itu, dan titik akhir yang tercatat mengikutinya. Klien yang menampilkan “tersambung” terus-menerus sepanjang perjalanan mengatakan hal yang benar.
Baris bawah juga bukan cacat. Membangun ulang sesi menjalankan kembali autentikasi terhadap alamat saat ini, yang justru merupakan hal yang Anda inginkan ketika alamat lama kini mungkin milik orang lain.
Amati peristiwanya, bukan pergerakannya
Di Android, subsistem konektivitas melaporkan perubahan jaringan sebagai peristiwa, dan itulah yang harus Anda korelasikan dengan perilaku klien. Dumpnya bertele-tele, tetapi bagian yang relevan adalah jaringan bawaan dan alamatnya:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40Di sisi server ada pengukuran langsung untuk kasus roaming. WireGuard menyimpan titik akhir terautentikasi terakhir per rekan, jadi perubahan alamat muncul sebagai nilai yang berubah alih-alih sebagai penyambungan ulang:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesBandingkan titik akhir sebelum dan setelah perjalanan. Jika alamat dan port tidak berubah, terowongan tidak perlu melakukan apa pun dan penyambungan ulang datang dari tempat lain, biasanya aplikasi. Jika titik akhir berubah sementara stempel waktu jabat tangan tetap dekat dengan interval pembaruan kunci normalnya, terowongan berpindah alih-alih memulai ulang.
Mulai ulang terlihat berbeda: stempel waktu jabat tangan diatur ulang ke saat penyambungan ulang, dan klien mencatat urutan inisialisasi alih-alih kelanjutan yang tenang.
Kapan penyambungan ulang adalah perilaku yang benar
Memperlakukan setiap penyambungan ulang sebagai kesalahan mengarah pada konfigurasi yang menjaga sesi mati tetap hidup. Rekan yang alamatnya berubah karena jaringan mengalokasikannya ulang tidak seharusnya terus menerima lalu lintas untuk pemetaan lama, dan klien yang diam-diam melanjutkan bisa berakhir mengirim ke lubang hitam sementara ikon tetap hijau.
Bandingkan dua kegagalan itu dari sudut pandang pengguna. Penyambungan ulang memakan beberapa detik dan autentikasi ulang. Terowongan basi memakan aplikasi yang menggantung tanpa kesalahan, yang jauh lebih sulit dijelaskan dan jauh lebih mungkin dilaporkan sebagai “internet rusak”.
Ada pula pertanyaan kebijakan yang tersembunyi di bawahnya. Selama celah antara kehilangan satu jalur dan membentuk jalur lain, sebagian klien kembali mengirim lalu lintas secara langsung. Mencegahnya adalah kontrol terpisah dari pemulihan otomatis, dan klien bisa bagus di satu hal dan buruk di hal lain. Putuskan mana yang Anda butuhkan sebelum menyetel keduanya.
Tuliskan urutan yang diamati
Laporan yang berguna menyebutkan sumber peristiwanya: perubahan jaringan bawaan dengan alamat baru, peralihan dari Wi-Fi ke seluler, atau perpindahan tanpa perubahan alamat sama sekali. Lalu laporan itu menyatakan apa yang dilakukan klien, dengan stempel waktu dari sisi server alih-alih dari ingatan.
Jika terowongan berpindah, katakan demikian dan catat keluarga titik akhir yang baru. Jika terbentuk ulang, catat apakah autentikasi berhasil pada percobaan pertama dan berapa lama celahnya. Ketiga fakta itu membedakan rancangan seluler yang sehat dari klien yang terombang-ambing antar jaringan.
Dan hindari frasa “pergantian menara” kecuali log perangkat benar-benar membuktikannya. Dokumentasi konektivitas Android menjelaskan callback yang membedakan ketersediaan dari perubahan jaringan bawaan, dan perbedaan itulah yang dibutuhkan laporan Anda. Selebihnya adalah cerita tentang menyetir.