Mengapa VPN anda terputus apabila Wi-Fi berubah atau Ethernet dipasang

Dua perkara dilaporkan sebagai satu kegagalan: komputer riba berpindah ke rangkaian Wi-Fi lain, atau kabel dipasang semasa Wi-Fi masih hidup. Klien masih berkata bersambung, ikon kelihatan sihat, dan terowong tidak membawa apa-apa. Di bawahnya, hanya tiga keping keadaan boleh bergerak - pautan, alamat setempat, laluan lalai - dan yang mana bergerak menentukan sama ada terowong pulih sendiri atau perlu menyambung semula. Saya menyemaknya dalam urutan itu, kerana menukar tetapan akaun tidak pernah membaiki mana-mana daripadanya.

Pautan, alamat dan laluan bergerak secara berasingan

Perayauan antara titik akses dalam rangkaian yang sama biasanya peristiwa L2. Radio menyekutukan semula, antara muka mengekalkan alamat dan getnya, dan tiada apa yang bergantung pada terowong berubah, itulah sebabnya berjalan merentas pejabat besar kadang-kadang tidak disedari. Menyertai SSID lain bukan itu: antara muka lama boleh turun, DHCP memberi alamat baharu, get baharu dan penyelesai baharu, dan aliran luar yang digunakan terowong tidak lagi wujud.

Ethernet menambah bentuk ketiga. Wi-Fi tidak pernah turun, jadi tiada peristiwa pautan dicetuskan langsung, tetapi antara muka berwayar muncul dengan alamatnya sendiri dan sering memenangi laluan lalai pada metrik. Terowong terus berjalan melalui laluan yang tidak lagi diutamakan, atau klien mengekalkan soketnya terpaku pada rangkaian wayarles tempat ia bermula. Dari pelayar kedua-duanya kelihatan sama: halaman tersekat pada saat kabel masuk.

Jadi soalan pertama bukan sama ada Wi-Fi berubah. Ia sama ada alamat yang anda terikat, atau laluan ke titik akhir, berubah semasa terowong hidup.

Soket luar terpaku pada alamat yang baru sahaja hilang

Setiap terowong ialah aliran luar: alamat dan port setempat bercakap dengan alamat dan port pelayan. Di Linux itu soket UDP terikat pada sumber lama; apabila antara muka yang memegang alamat dibuang, penghantaran sama ada gagal dengan EADDRNOTAVAIL atau keluar melalui antara muka baharu dengan sumber yang tidak pernah dilihat pelayan.

Sisi jauh menyimpan pakunya sendiri. SA IKEv2 tanpa MOBIKE dikenal pasti oleh pasangan alamat, dan OpenVPN sesi terikat pada alamat rakan yang dipelajarinya, dan pemetaan NAT milik alamat persendirian, port dan alamat awam yang menciptanya. Bergerak di belakang NAT lain dan setiap balasan dihantar ke pemetaan yang tidak lagi wujud. Tiada apa yang salah dikonfigurasikan pada mesin anda; lima-tupel itu menunjuk ke rangkaian yang anda tinggalkan.

Baca keadaan sebelum berteori:

• ss -unp menunjukkan alamat dan port setempat yang benar-benar dipegang oleh setiap soket terowong.
• ip route get 203.0.113.10 mencetak alamat sumber dan peranti yang akan digunakan kernel untuk titik akhir sekarang.
• wg show wg0 endpoints, swanctl --list-sas atau log klien menunjukkan alamat rakan yang disangka sisi jauh sedang bercakap.

Jika alamat soket dan carian laluan tidak bersetuju, anda telah menemui pecahan itu, dan tiada perubahan kelayakan akan menyentuhnya.

Apa yang setiap protokol lakukan dengan alamat sumber baharu

Klien menyerap perubahan pada tahap berbeza, dan jadual itulah yang saya bandingkan dengan konfigurasi klien dan bukannya meneka daripada tingkah laku penyambungan semula.

Peraturan perayauan WireGuard hanya berfungsi dalam satu arah: klien mesti menghantar dari alamat baharu dahulu. Soket yang masih terikat pada antara muka lama tidak pernah berbuat demikian, itulah sebabnya terowong boleh kelihatan hidup sementara pemasa jabat tangan menua. huraian protokol menyatakan syarat kemas kini titik akhir dengan tepat, dan ia wajar dibaca sebelum anda menukar konfigurasi.

MOBIKE dirundingkan, bukan diandaikan. Jika pelayan tidak menawarkannya, klien mesti membina semula, dan itu fakta yang anda pastikan daripada senarai SA atau log, bukan yang anda simpulkan daripada roda berputar.

Keutamaan laluan menentukan jalan, bukan ikon Wi-Fi

Dengan kedua-dua antara muka hidup, kernel memilih mengikut metrik dan panjang awalan. ip route show default menyenaraikan calon dan ip route get 203.0.113.10 menyelesaikan keputusan sebenar, termasuk alamat sumber. Laluan lalai berwayar pada metrik 100 dan wayarles pada 600 bermakna titik akhir bergerak pada saat kabel duduk, sementara setiap aplikasi yang membuka soket lebih awal mengekalkan sumber lamanya.

Windows melakukan perkara yang sama dengan metrik antara muka automatik, dipesongkan oleh kelajuan pautan. Get-NetRoute -DestinationPrefix 0.0.0.0/0 menyusun calon dan Find-NetRoute -RemoteIPAddress 203.0.113.10 mengembalikan antara muka dan sumber yang akan dipilih oleh tindanan. Klien yang mengikat soket luarnya pada satu antara muka terus menggunakannya selepas metrik berpaling; itu keputusan pengikatan, bukan kerosakan penghalaan.

Android menjadikan pemisahan itu kelihatan: ConnectivityManager melaporkan rangkaian tersedia dan lalai berasingan, dan aplikasi VPN yang mengikat soket pada objek Network mengekalkan ikatan itu sehingga ia mengikat semula. Di macOS, scutil --nwi mencetak antara muka utama dan urutan yang akan digunakan sistem.

DNS, MTU dan IPv6 bergerak bersama sambungan

Sambungan baharu membawa penyelesai baharu. Dengan systemd-resolved DNS adalah per pautan, resolvectl status menunjukkan pautan mana yang menjawab sesuatu nama, dan rangkaian tetamu yang mengagihkan penyelesainya sendiri boleh membiarkan DNS yang ditolak terowong tidak digunakan sehingga pautan diutamakan semula. Portal tawanan memburukkannya: permintaan HTTPS pertama dijawab portal dan bukan titik akhir, dan klien merekodkan pelayan mati.

MTU laluan juga berubah. Ethernet dan Wi-Fi biasanya membawa 1500 bait, PPPoE 1492, dan pautan mudah alih selalunya kurang. Terowong yang mewarisi MTU lebih kecil tersekat pada paket besar sementara permintaan kecil berjaya, yang dibaca sebagai sambungan separuh rosak. ping -M do -s 1472 203.0.113.10 menghantar paket 1500 bait dengan DF ditetapkan; kesenyapan bermakna laluan lebih kecil daripada yang anda andaikan.

IPv6 ialah separuh lagi. Rangkaian yang mengagihkan awalan baharu menukar sumber yang akan digunakan klien dwi-tindanan, dan terowong v4 sahaja membiarkan trafik v6 di luarnya sehingga dasar menyusul. ip -6 route show default dan ip -6 addr show menjawab sama ada pautan baharu mempunyai laluan v6 sama sekali.

Hasilkan semula peralihan itu dan bukannya menghuraikannya

Pilih satu permintaan tidak berbahaya dan jalankan tiga arahan yang sama di kedua-dua belah perubahan: ip -br addr, ip route show default, ip route get 203.0.113.10. Kemudian perhatikan sama ada terowong masih memancarkan paket - tcpdump -ni any udp port 51820 untuk WireGuard, port yang sepadan untuk apa-apa lagi. Paket yang keluar dari sumber lama bermakna masalah pengikatan. Paket dari sumber baharu tanpa balasan bermakna sisi jauh atau NAT di antaranya.

Catat peristiwa mana yang bertepatan dengan kegagalan pertama: pautan turun, perubahan alamat, atau perubahan laluan lalai. Itu menunjuk kepada pemilik berbeza - klien yang perlu mengikat semula, alamat yang perlu diperoleh semula, atau laluan yang dimiliki fail konfigurasi dan bukan peraturan pintasan kekal.

Sebelum menyebutnya sudah dibaiki, pastikan blok trafik langsung masih bertahan sepanjang jurang dan nama diselesaikan melalui sambungan baharu. Jika klien mengekalkan titik akhir lama selepas pertukaran, baiki tetapan perayauan atau float dahulu. Jika ia merayau dengan betul dan masih tidak menerima balasan, lihat identiti rakan di pelayan dan NAT pada laluan, dan simpan kedua-dua konteks rangkaian dalam catatan supaya orang seterusnya boleh membandingkannya.