Kial via VPN falas kiam Wi-Fi ŝanĝiĝas aŭ Ethernet enŝoviĝas
'Nova SSID, migrado inter alirpunktoj kaj enŝovita kablo rompas tunelon en tri malsamaj lokoj. Kontrolu la fontadreson, poste la itineron, poste la protokolon.'
Du aferoj estas raportataj kiel unu fiasko: la tekkomputilo transiris al alia Wi-Fi-reto, aŭ kablo enŝoviĝis dum Wi-Fi restis aktiva. La kliento ankoraŭ diras konektita, la piktogramo aspektas sana, kaj la tunelo portas nenion. Sube nur tri pecoj de stato povas moviĝi - la ligo, la loka adreso, la implicita itinero - kaj kiuj moviĝis decidas ĉu la tunelo resaniĝos mem aŭ bezonos rekonekton. Mi kontrolas ilin en tiu ordo, ĉar ŝanĝi kontajn agordojn neniam riparis iun el ili.
Ligo, adreso kaj itinero moviĝas sendepende
Migrado inter alirpunktoj en la sama reto estas kutime okazaĵo de L2. La radio reasociiĝas, la interfaco konservas sian adreson kaj pordegon, kaj nenio de kio la tunelo dependas ŝanĝiĝas, tial promeno tra granda oficejo foje pasas nerimarkite. Aliĝi al alia SSID ne estas tio: la malnova interfaco povas fali, DHCP donas novan adreson, novan pordegon kaj novajn solvilojn, kaj la ekstera fluo kiun la tunelo uzis ĉesas ekzisti.
Ethernet aldonas trian formon. Wi-Fi neniam falas, do neniu ligokazaĵo ekbrulas, tamen la drata interfaco aperas kun propra adreso kaj ofte gajnas la implicitan itineron laŭ metriko. La tunelo daŭre funkcias sur vojo kiu ne plu estas preferata, aŭ la kliento tenas sian poŝon fiksita al la sendrata reto sur kiu ĝi komenciĝis. De la retumilo ambaŭ aspektas same: paĝoj haltas en la momento kiam la kablo klakas.
Do la unua demando ne estas ĉu Wi-Fi ŝanĝiĝis. Ĝi estas ĉu la adreso al kiu vi estas ligitaj, aŭ la itinero al la finpunkto, ŝanĝiĝis dum la tunelo estis aktiva.
La ekstera poŝo estas fiksita al adreso kiu ĵus malaperis
Ĉiu tunelo estas ekstera fluo: loka adreso kaj pordo parolantaj kun la adreso kaj pordo de la servilo. En Linux tio estas UDP-poŝo ligita al la malnova fonto; kiam la interfaco tenanta la adreson foriĝas, sendo aŭ fiaskas per EADDRNOTAVAIL aŭ eliras tra la nova interfaco kun fonto kiun la servilo neniam vidis.
La fora flanko tenas sian propran fiksilon. SA de IKEv2 sen MOBIKE identiĝas per la adresparo, kaj OpenVPN seanco estas ligita al la partnera adreso kiun ĝi lernis, kaj NAT-mapado apartenas al la privata adreso, pordo kaj publika adreso kiuj kreis ĝin. Moviĝu malantaŭ alian NAT kaj ĉiu respondo iras al mapado kiu ne plu ekzistas. Nenio sur via maŝino estas malĝuste agordita; la kvinopo montras al reto kiun vi forlasis.
Legu la staton antaŭ ol teoriadi:
ss -unpmontras la lokan adreson kaj pordon kiujn ĉiu tunela poŝo efektive tenas.ip route get 203.0.113.10presas la fontadreson kaj la aparaton kiujn la kerno nun uzus por la finpunkto.wg show wg0 endpoints,swanctl --list-sasaŭ la klienta protokolo montras la partneran adreson kun kiu la fora flanko kredas paroli.
Se la poŝa adreso kaj la itinera serĉo malkongruas, vi trovis la rompon, kaj nenia ŝanĝo de akreditaĵoj tuŝos ĝin.
Kion ĉiu protokolo faras kun nova fontadreso
Klientoj sorbas la ŝanĝon diversgrade, kaj la tabelo estas tio kun kio mi komparas la klientan agordon anstataŭ diveni el la rekonekta konduto.
| 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. |
La migra regulo de WireGuard funkcias nur en unu direkto: la kliento devas unue sendi el la nova adreso. Poŝo ankoraŭ ligita al la malnova interfaco tion neniam faras, tial tunelo povas aspekti viva dum ĝia manprema tempigilo maljuniĝas. priskribo de la protokolo precize diras la kondiĉon por ĝisdatigi la finpunkton, kaj indas legi ĝin antaŭ ol ŝanĝi agordon.
MOBIKE estas intertraktata, ne supozata. Se la servilo ne proponas ĝin, la kliento devas restarigi, kaj tio estas fakto kiun vi konfirmas el la SA-listo aŭ la protokolo anstataŭ dedukti el turniĝanta rado.
Itinera prefero decidas la vojon, ne la Wi-Fi-piktogramo
Kun ambaŭ interfacoj supraj, la kerno elektas laŭ metriko kaj prefiksa longo. ip route show default listigas la kandidatojn kaj ip route get 203.0.113.10 solvas la realan decidon, inkluzive de la fontadreso. Drata implicita itinero ĉe metriko 100 kaj sendrata ĉe 600 signifas ke la finpunkto moviĝas en la momento kiam la kablo sidiĝas, dum ĉiu aplikaĵo kiu malfermis poŝon pli frue konservas sian malnovan fonton.
Windows faras la samon per aŭtomataj interfacaj metrikoj, influataj de liga rapideco. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ordigas la kandidatojn kaj Find-NetRoute -RemoteIPAddress 203.0.113.10 redonas la interfacon kaj fonton kiujn la stako elektus. Kliento kiu ligas sian eksteran poŝon al unu interfaco daŭre uzas ĝin post kiam la metriko renversiĝas; tio estas liga decido, ne itinera difekto.
Android igas la disigon videbla: ConnectivityManager raportas disponeblajn retojn kaj apartan implicitan, kaj VPN-aplikaĵo kiu ligas poŝon al objekto Network tenas tiun ligon ĝis ĝi religas. En macOS, scutil --nwi presas la primaran interfacon kaj la ordon kiun la sistemo uzus.
DNS, MTU kaj IPv6 moviĝas kun la alkroĉo
Nova alkroĉo alportas novajn solvilojn. Kun systemd-resolved DNS estas laŭliga, resolvectl status montras kiun ligon respondas nomon, kaj gastiga reto kiu disdonas sian propran solvilon povas lasi la DNS-puŝitan de la tunelo neuzata ĝis la ligo denove preferiĝos. Kapta portalo plimalbonigas tion: la unuan HTTPS-peton respondas la portalo anstataŭ la finpunkto, kaj la kliento registras mortan servilon.
Ankaŭ la voja MTU ŝanĝiĝas. Ethernet kaj Wi-Fi kutime portas 1500 bajtojn, PPPoE 1492, kaj movaj ligoj ofte malpli. Tunelo kiu heredas pli malgrandan MTU haltas ĉe grandaj pakoj dum malgrandaj petoj sukcesas, kio legeblas kiel duone rompita konekto. ping -M do -s 1472 203.0.113.10 sendas pakon de 1500 bajtoj kun DF ŝaltita; silento signifas ke la vojo estas pli malgranda ol vi supozis.
IPv6 estas la alia duono. Reto kiu disdonas novan prefikson ŝanĝas la fonton kiun dukolona kliento uzus, kaj tunelo nur-v4 lasas v6-trafikon ekster si ĝis la politiko atingas. ip -6 route show default kaj ip -6 addr show respondas ĉu la nova ligo entute havas v6-vojon.
Reproduktu la transiron anstataŭ priskribi ĝin
Elektu unu sendanĝeran peton kaj rulu la samajn tri komandojn ambaŭflanke de la ŝanĝo: ip -br addr, ip route show default, ip route get 203.0.113.10. Poste observu ĉu la tunelo ankoraŭ elsendas pakojn - tcpdump -ni any udp port 51820 por WireGuard, la konforma pordo por io ajn alia. Pakoj elirantaj el la malnova fonto signifas ligan problemon. Pakoj el la nova fonto sen respondo signifas la foran flankon aŭ la NAT-on intere.
Notu kiu okazaĵo koincidis kun la unua fiasko: liga falo, adresa ŝanĝo aŭ ŝanĝo de la implicita itinero. Tiuj montras al malsamaj posedantoj - kliento kiu devas religi, adreso kiu devas esti reakirita, aŭ itinero kiu apartenas al agorda dosiero kaj ne al daŭra pretervoja regulo.
Antaŭ ol nomi ĝin riparita, konfirmu ke la bloko por rekta trafiko ankoraŭ tenas dum la paŭzo kaj ke nomoj solviĝas tra la nova alkroĉo. Se la kliento tenas la malnovan finpunkton post la ŝalto, unue riparu la migran aŭ float-agordon. Se ĝi migras ĝuste kaj ankoraŭ ne ricevas respondon, rigardu la partneran identecon de la servilo kaj la NAT-on sur la vojo, kaj konservu ambaŭ retajn kuntekstojn en la raporto por ke la sekva persono povu kompari ilin.