Mengapa VPN Anda putus saat Wi-Fi berganti atau Ethernet dicolokkan
'SSID baru, roaming antar titik akses, dan kabel yang dicolokkan memutus tunnel di tiga tempat berbeda. Periksa alamat sumber, lalu rute, lalu protokol.'
Dua hal dilaporkan sebagai satu kegagalan: laptop berpindah ke jaringan Wi-Fi lain, atau kabel dicolokkan sementara Wi-Fi tetap hidup. Klien masih bilang terhubung, ikonnya tampak sehat, dan tunnel tidak membawa apa pun. Di bawahnya, hanya tiga bagian status yang bisa bergerak - tautan, alamat lokal, rute default - dan bagian mana yang bergerak menentukan apakah tunnel pulih sendiri atau perlu menyambung ulang. Saya memeriksanya dalam urutan itu, karena mengubah pengaturan akun tidak pernah memperbaiki satu pun darinya.
Tautan, alamat, dan rute bergerak secara terpisah
Roaming antar titik akses di jaringan yang sama biasanya peristiwa L2. Radio mengasosiasikan ulang, antarmuka mempertahankan alamat dan gateway-nya, dan tidak ada yang menjadi sandaran tunnel berubah, itulah sebabnya berjalan melintasi kantor besar kadang tidak terasa. Bergabung ke SSID lain bukan itu: antarmuka lama bisa turun, DHCP memberi alamat baru, gateway baru, dan resolver baru, dan aliran luar yang dipakai tunnel berhenti ada.
Ethernet menambah bentuk ketiga. Wi-Fi tidak pernah putus, jadi tidak ada peristiwa tautan yang dipicu sama sekali, tetapi antarmuka kabel muncul dengan alamatnya sendiri dan sering memenangkan rute default berdasarkan metrik. Tunnel tetap berjalan lewat jalur yang tidak lagi dipilih, atau klien menahan soketnya terpaku ke jaringan nirkabel tempat ia memulai. Dari peramban keduanya tampak sama: halaman macet begitu kabel terkunci.
Jadi pertanyaan pertama bukan apakah Wi-Fi berubah. Melainkan apakah alamat tempat Anda terikat, atau rute ke titik akhir, berubah saat tunnel hidup.
Soket luar terpaku pada alamat yang baru saja hilang
Setiap tunnel adalah aliran luar: alamat dan porta lokal yang berbicara dengan alamat dan porta server. Di Linux itu soket UDP yang terikat ke sumber lama; ketika antarmuka pemegang alamat dihapus, pengiriman gagal dengan EADDRNOTAVAIL atau keluar lewat antarmuka baru dengan sumber yang belum pernah dilihat server.
Sisi jauh menyimpan pakunya sendiri. SA IKEv2 tanpa MOBIKE dikenali dari pasangan alamat, dan OpenVPN sesi terikat pada alamat peer yang dipelajarinya, dan pemetaan NAT milik alamat privat, porta, dan alamat publik yang membuatnya. Pindah ke balik NAT lain dan setiap balasan dikirim ke pemetaan yang tidak ada lagi. Tidak ada yang salah konfigurasi di mesin Anda; lima-tupel itu menunjuk ke jaringan yang Anda tinggalkan.
Baca statusnya sebelum berteori:
ss -unpmenunjukkan alamat dan porta lokal yang benar-benar dipegang setiap soket tunnel.ip route get 203.0.113.10mencetak alamat sumber dan perangkat yang akan dipakai kernel untuk titik akhir saat ini.wg show wg0 endpoints,swanctl --list-sasatau log klien menunjukkan alamat peer yang menurut sisi jauh sedang diajak bicara.
Jika alamat soket dan pencarian rute tidak sepakat, Anda telah menemukan patahannya, dan tidak ada perubahan kredensial yang akan menyentuhnya.
Apa yang dilakukan setiap protokol dengan alamat sumber baru
Klien menyerap perubahan pada kadar berbeda, dan tabel itulah yang saya bandingkan dengan konfigurasi klien alih-alih menebak dari perilaku penyambungan ulang.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
Aturan roaming WireGuard hanya bekerja satu arah: klien harus mengirim dari alamat baru lebih dulu. Soket yang masih terikat ke antarmuka lama tidak pernah melakukannya, itulah sebabnya tunnel bisa tampak hidup sementara pengatur waktu jabat tangannya menua. penjelasan protokol menyatakan syarat pembaruan titik akhir dengan tepat, dan layak dibaca sebelum Anda mengubah konfigurasi.
MOBIKE dinegosiasikan, bukan diasumsikan. Jika server tidak menawarkannya, klien harus membangun ulang, dan itu fakta yang Anda pastikan dari daftar SA atau log, bukan yang Anda simpulkan dari roda berputar.
Preferensi rute yang menentukan jalur, bukan ikon Wi-Fi
Dengan kedua antarmuka hidup, kernel memilih berdasarkan metrik dan panjang prefiks. ip route show default mendaftar kandidatnya dan ip route get 203.0.113.10 menyelesaikan keputusan sebenarnya, termasuk alamat sumber. Rute default kabel pada metrik 100 dan nirkabel pada 600 berarti titik akhir bergerak begitu kabel terpasang, sementara setiap aplikasi yang membuka soket lebih dulu mempertahankan sumber lamanya.
Windows melakukan hal yang sama dengan metrik antarmuka otomatis, dibiaskan oleh kecepatan tautan. Get-NetRoute -DestinationPrefix 0.0.0.0/0 mengurutkan kandidatnya dan Find-NetRoute -RemoteIPAddress 203.0.113.10 mengembalikan antarmuka dan sumber yang akan dipilih tumpukan. Klien yang mengikat soket luarnya ke satu antarmuka terus memakainya setelah metrik berbalik; itu keputusan pengikatan, bukan kesalahan perutean.
Android membuat pemisahan itu terlihat: ConnectivityManager melaporkan jaringan yang tersedia dan default terpisah, dan aplikasi VPN yang mengikat soket ke objek Network mempertahankan ikatan itu sampai mengikat ulang. Di macOS, scutil --nwi mencetak antarmuka utama dan urutan yang akan dipakai sistem.
DNS, MTU, dan IPv6 bergerak bersama sambungan
Sambungan baru membawa resolver baru. Dengan systemd-resolved DNS bersifat per tautan, resolvectl status menunjukkan tautan mana yang menjawab sebuah nama, dan jaringan tamu yang membagikan resolver sendiri bisa membuat DNS yang didorong tunnel tidak terpakai sampai tautan kembali dipilih. Portal tawanan memperburuknya: permintaan HTTPS pertama dijawab portal alih-alih titik akhir, dan klien mencatat server mati.
MTU jalur juga berubah. Ethernet dan Wi-Fi biasanya membawa 1500 byte, PPPoE 1492, dan tautan seluler sering lebih sedikit. Tunnel yang mewarisi MTU lebih kecil macet pada paket besar sementara permintaan kecil berhasil, yang terbaca sebagai koneksi setengah rusak. ping -M do -s 1472 203.0.113.10 mengirim paket 1500 byte dengan DF disetel; kesunyian berarti jalurnya lebih kecil dari dugaan Anda.
IPv6 adalah separuh lainnya. Jaringan yang membagikan prefiks baru mengubah sumber yang akan dipakai klien tumpukan ganda, dan tunnel hanya v4 membiarkan lalu lintas v6 di luarnya sampai kebijakan menyusul. ip -6 route show default dan ip -6 addr show menjawab apakah tautan baru punya jalur v6 sama sekali.
Reproduksi transisinya alih-alih mendeskripsikannya
Pilih satu permintaan tak berbahaya dan jalankan tiga perintah yang sama di kedua sisi perubahan: ip -br addr, ip route show default, ip route get 203.0.113.10. Lalu amati apakah tunnel masih memancarkan paket - tcpdump -ni any udp port 51820 untuk WireGuard, porta yang sesuai untuk apa pun yang lain. Paket yang keluar dari sumber lama berarti masalah pengikatan. Paket dari sumber baru tanpa balasan berarti sisi jauh atau NAT di antaranya.
Catat peristiwa mana yang bertepatan dengan kegagalan pertama: tautan turun, perubahan alamat, atau perubahan rute default. Itu menunjuk ke pemilik berbeda - klien yang harus mengikat ulang, alamat yang harus diperoleh ulang, atau rute yang milik berkas konfigurasi dan bukan aturan pintas permanen.
Sebelum menyebutnya beres, pastikan blok lalu lintas langsung masih bertahan selama jeda dan nama-nama terurai lewat sambungan baru. Jika klien menahan titik akhir lama setelah peralihan, perbaiki dulu pengaturan roaming atau float. Jika ia merayap dengan benar dan tetap tidak menerima balasan, lihat identitas peer di server dan NAT di jalurnya, dan simpan kedua konteks jaringan dalam catatan agar orang berikutnya bisa membandingkannya.