Miksi VPN-yhteytesi katkeaa, kun Wi-Fi vaihtuu tai Ethernet kytketään
'Uusi SSID, verkkovierailu tukiasemien välillä ja kytketty kaapeli rikkovat tunnelin kolmessa eri kohdassa. Tarkista lähdeosoite, sitten reitti ja sitten protokolla.'
Kaksi asiaa raportoidaan yhtenä vikana: kannettava siirtyi toiseen Wi-Fi-verkkoon, tai kaapeli kytkettiin, kun Wi-Fi pysyi päällä. Asiakas sanoo yhä olevansa yhteydessä, kuvake näyttää terveeltä, eikä tunneli kuljeta mitään. Pinnan alla vain kolme tilan palaa voi liikkua - linkki, paikallinen osoite, oletusreitti - ja se, mikä niistä liikkui, ratkaisee, palautuuko tunneli itsestään vai tarvitseeko se uuden yhteyden. Tarkistan ne tässä järjestyksessä, koska tilin asetusten muuttaminen ei ole koskaan korjannut yhtäkään niistä.
Linkki, osoite ja reitti liikkuvat toisistaan riippumatta
Verkkovierailu saman verkon tukiasemien välillä on yleensä L2-tapahtuma. Radio liittyy uudelleen, liitäntä säilyttää osoitteensa ja yhdyskäytävänsä, eikä mikään, josta tunneli riippuu, muutu, minkä vuoksi kävely suuressa toimistossa jää joskus huomaamatta. Toiseen SSID:hen liittyminen ei ole sitä: vanha liitäntä voi pudota, DHCP jakaa uuden osoitteen, uuden yhdyskäytävän ja uudet selvittimet, ja ulompi virtaus, jota tunneli käytti, lakkaa olemasta.
Ethernet lisää kolmannen muodon. Wi-Fi ei koskaan putoa, joten yhtään linkkitapahtumaa ei synny, mutta johdollinen liitäntä ilmestyy omalla osoitteellaan ja voittaa usein oletusreitin metriikalla. Tunneli jatkaa reitillä, joka ei enää ole ensisijainen, tai asiakas pitää pistokkeensa kiinnitettynä langattomaan verkkoon, jossa se aloitti. Selaimesta molemmat näyttävät samalta: sivut pysähtyvät heti, kun kaapeli naksahtaa.
Ensimmäinen kysymys ei siis ole, vaihtuiko Wi-Fi. Se on, vaihtuiko osoite, johon olet sidottu, tai reitti päätepisteeseen, kun tunneli oli päällä.
Ulompi pistoke on kiinnitetty osoitteeseen, joka juuri katosi
Jokainen tunneli on ulompi virtaus: paikallinen osoite ja portti, jotka puhuvat palvelimen osoitteen ja portin kanssa. Linuxissa se on UDP-pistoke, joka on sidottu vanhaan lähteeseen; kun osoitteen sisältävä liitäntä poistetaan, lähetykset joko epäonnistuvat EADDRNOTAVAIL-virheeseen tai lähtevät uuden liitännän kautta lähteellä, jota palvelin ei ole koskaan nähnyt.
Vastapuoli pitää oman kiinnityksensä. IKEv2-SA ilman MOBIKEa tunnistetaan osoiteparista, ja OpenVPN-istunto on sidottu siihen vertaisosoitteeseen, jonka se oppi, ja NAT-mappaus kuuluu sille yksityiselle osoitteelle, portille ja julkiselle osoitteelle, jotka sen loivat. Siirry toisen NATin taakse, ja jokainen vastaus lähetetään mappaukselle, jota ei enää ole. Koneessasi ei ole mitään väärin asetettua; viisikko osoittaa verkkoon, jonka jätit.
Lue tila ennen kuin teoretisoit:
ss -unpnäyttää paikallisen osoitteen ja portin, jotka kukin tunnelipistoke todella pitää.ip route get 203.0.113.10tulostaa lähdeosoitteen ja laitteen, jota ydin käyttäisi päätepisteeseen juuri nyt.wg show wg0 endpoints,swanctl --list-sastai asiakkaan loki näyttää vertaisosoitteen, jonka kanssa vastapuoli luulee puhuvansa.
Jos pistokkeen osoite ja reittihaku ovat eri mieltä, olet löytänyt katkoksen, eikä mikään tunnistetietojen muutos kosketa sitä.
Mitä kukin protokolla tekee uudella lähdeosoitteella
Asiakkaat imevät muutoksen eri asteisesti, ja taulukko on se, johon vertaan asiakkaan kokoonpanoa sen sijaan että arvaisin uudelleenyhdistämiskäyttäytymisestä.
| 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. |
WireGuardin verkkovierailusääntö toimii vain yhteen suuntaan: asiakkaan on ensin lähetettävä uudesta osoitteesta. Vanhaan liitäntään yhä sidottu pistoke ei koskaan tee niin, minkä vuoksi tunneli voi näyttää elävältä, kun sen kättelyajastin vanhenee. protokollan kuvaus ilmaisee päätepisteen päivitysehdon täsmällisesti, ja se kannattaa lukea ennen kokoonpanon muuttamista.
MOBIKE neuvotellaan, sitä ei oleteta. Jos palvelin ei tarjoa sitä, asiakkaan on muodostettava yhteys uudelleen, ja se on tosiasia, jonka vahvistat SA-listasta tai lokista etkä päättele pyörivästä rattaasta.
Reitin etusija ratkaisee polun, ei Wi-Fi-kuvake
Kun molemmat liitännät ovat ylhäällä, ydin valitsee metriikan ja etuliitteen pituuden mukaan. ip route show default luettelee ehdokkaat ja ip route get 203.0.113.10 ratkaisee varsinaisen päätöksen, lähdeosoite mukaan lukien. Johdollinen oletusreitti metriikalla 100 ja langaton arvolla 600 tarkoittavat, että päätepiste siirtyy heti, kun kaapeli asettuu, kun taas jokainen sovellus, joka avasi pistokkeen aiemmin, pitää vanhan lähteensä.
Windows tekee saman automaattisilla liitäntämetriikoilla, linkin nopeuden vinouttamana. Get-NetRoute -DestinationPrefix 0.0.0.0/0 lajittelee ehdokkaat ja Find-NetRoute -RemoteIPAddress 203.0.113.10 palauttaa liitännän ja lähteen, jonka pino valitsisi. Asiakas, joka sitoo ulomman pistokkeensa yhteen liitäntään, käyttää sitä edelleen metriikan käännyttyä; se on sidontapäätös, ei reititysvika.
Android tekee jaosta näkyvän: ConnectivityManager ilmoittaa käytettävissä olevat verkot ja erillisen oletuksen, ja VPN-sovellus, joka sitoo pistokkeen Network-objektiin, pitää sidonnan, kunnes sitoo sen uudelleen. macOS:ssä scutil --nwi tulostaa ensisijaisen liitännän ja järjestyksen, jota järjestelmä käyttäisi.
DNS, MTU ja IPv6 liikkuvat liittymisen mukana
Uusi liittyminen tuo uudet selvittimet. systemd-resolvedin kanssa DNS on linkkikohtainen, resolvectl status näyttää, mikä linkki vastaa nimeen, ja vierasverkko, joka jakaa oman selvittimensä, voi jättää tunnelin työntämän DNS:n käyttämättä, kunnes linkki tulee uudelleen ensisijaiseksi. Vangitseva portaali pahentaa sitä: ensimmäiseen HTTPS-pyyntöön vastaa portaali päätepisteen sijaan, ja asiakas kirjaa kuolleen palvelimen.
Myös polun MTU muuttuu. Ethernet ja Wi-Fi kuljettavat yleensä 1500 tavua, PPPoE 1492, ja mobiililinkit usein vähemmän. Tunneli, joka perii pienemmän MTUn, jumittuu suurilla paketeilla pienten pyyntöjen onnistuessa, mikä luetaan puoliksi rikkinäiseksi yhteydeksi. ping -M do -s 1472 203.0.113.10 lähettää 1500 tavun paketin DF asetettuna; hiljaisuus tarkoittaa, että polku on pienempi kuin oletit.
IPv6 on toinen puoli. Verkko, joka jakaa uuden etuliitteen, muuttaa lähdettä, jota kaksoispinon asiakas käyttäisi, ja vain v4-tunneli jättää v6-liikenteen ulkopuolelleen, kunnes käytäntö ehtii perässä. ip -6 route show default ja ip -6 addr show vastaavat, onko uudella linkillä ylipäätään v6-polkua.
Toista siirtymä sen kuvaamisen sijaan
Valitse yksi harmiton pyyntö ja aja samat kolme komentoa muutoksen molemmin puolin: ip -br addr, ip route show default, ip route get 203.0.113.10. Seuraa sitten, lähettääkö tunneli yhä paketteja - tcpdump -ni any udp port 51820 WireGuardille, vastaava portti kaikelle muulle. Vanhasta lähteestä lähtevät paketit tarkoittavat sidontaongelmaa. Uudesta lähteestä ilman vastausta lähtevät paketit tarkoittavat vastapuolta tai välissä olevaa NATia.
Kirjaa, mikä tapahtuma osui ensimmäisen vian kanssa samaan: linkin pudotus, osoitteen muutos tai oletusreitin muutos. Ne osoittavat eri omistajiin - asiakas, joka on sidottava uudelleen, osoite, joka on hankittava uudelleen, tai reitti, joka kuuluu kokoonpanotiedostoon eikä pysyvään ohitussääntöön.
Ennen kuin sanot sitä korjatuksi, varmista, että suoran liikenteen estolohko pitää yhä katkoksen ajan ja että nimet selvitetään uuden liittymisen kautta. Jos asiakas pitää vanhan päätepisteen vaihdon jälkeen, korjaa ensin verkkovierailu- tai float-asetus. Jos se vierailee oikein eikä silti saa vastausta, katso palvelimen vertaisidentiteettiä ja polun NATia, ja pidä molemmat verkkokontekstit kirjoituksessa, jotta seuraava henkilö voi verrata niitä.