Waarom je VPN wegvalt als Wi-Fi wisselt of Ethernet wordt ingestoken

Twee dingen worden als één storing gemeld: de laptop is naar een ander Wi-Fi-netwerk gegaan, of er is een kabel ingestoken terwijl Wi-Fi bleef draaien. De client zegt nog steeds verbonden, het pictogram ziet er gezond uit, en de tunnel vervoert niets. Onder de oppervlakte kunnen maar drie stukken toestand verschuiven - de verbinding, het lokale adres, de standaardroute - en welk stuk verschoof bepaalt of de tunnel zichzelf herstelt of opnieuw moet verbinden. Ik controleer ze in die volgorde, omdat het wijzigen van accountinstellingen er nog nooit een heeft verholpen.

Verbinding, adres en route verschuiven onafhankelijk

Roaming tussen accesspoints in hetzelfde netwerk is meestal een L2-gebeurtenis. De radio associeert opnieuw, de interface behoudt zijn adres en gateway, en niets waarvan de tunnel afhangt verandert, waardoor een wandeling door een groot kantoor soms ongemerkt voorbijgaat. Verbinden met een andere SSID is dat niet: de oude interface kan wegvallen, DHCP deelt een nieuw adres uit, een nieuwe gateway en nieuwe resolvers, en de buitenste stroom die de tunnel gebruikte houdt op te bestaan.

Ethernet voegt een derde vorm toe. Wi-Fi valt nooit weg, dus er wordt helemaal geen verbindingsgebeurtenis afgevuurd, maar de bedrade interface verschijnt met een eigen adres en wint vaak de standaardroute op metriek. De tunnel blijft doorlopen over een pad dat niet langer de voorkeur heeft, of de client houdt zijn socket vastgepind aan het draadloze netwerk waarop hij begon. Vanuit de browser zien beide er hetzelfde uit: pagina's stokken op het moment dat de kabel klikt.

De eerste vraag is dus niet of Wi-Fi veranderde. Het is of het adres waaraan je gebonden bent, of de route naar het eindpunt, veranderde terwijl de tunnel actief was.

De buitenste socket is vastgepind aan een adres dat net verdween

Elke tunnel is een buitenste stroom: een lokaal adres en poort die praten met het adres en de poort van de server. Op Linux is dat een UDP-socket gebonden aan de oude bron; wanneer de interface die het adres houdt wordt verwijderd, mislukken verzendingen met EADDRNOTAVAIL of gaan ze via de nieuwe interface naar buiten met een bron die de server nooit heeft gezien.

De verre kant houdt zijn eigen pin vast. Een IKEv2-SA zonder MOBIKE wordt geïdentificeerd door het adrespaar, en een OpenVPN-sessie is gebonden aan het peeradres dat hij leerde, en een NAT-mapping hoort bij het privéadres, de poort en het openbare adres die hem hebben gemaakt. Ga achter een andere NAT zitten en elk antwoord gaat naar een mapping die niet meer bestaat. Niets op je machine is verkeerd geconfigureerd; de vijf-tupel wijst naar een netwerk dat je hebt verlaten.

Lees de toestand voordat je gaat theoretiseren:

• ss -unp toont het lokale adres en de poort die elke tunnel-socket werkelijk houdt.
• ip route get 203.0.113.10 drukt het bronadres en het apparaat af die de kernel nu voor het eindpunt zou gebruiken.
• wg show wg0 endpoints, swanctl --list-sas of de clientlog toont het peeradres waarmee de verre kant denkt te praten.

Als het socketadres en de routeopzoeking het niet eens zijn, heb je de breuk gevonden, en geen enkele inloggegevenswijziging zal eraan raken.

Wat elk protocol doet met een nieuw bronadres

Clients absorberen de verandering in verschillende mate, en de tabel is wat ik met de clientconfiguratie vergelijk in plaats van te gokken op grond van het herverbindingsgedrag.

De roamingregel van WireGuard werkt maar één kant op: de client moet eerst vanaf het nieuwe adres versturen. Een socket die nog aan de oude interface gebonden is, doet dat nooit, waardoor een tunnel levend kan lijken terwijl zijn handshake-timer veroudert. protocolbeschrijving vermeldt de voorwaarde voor het bijwerken van het eindpunt precies, en het is de moeite waard die te lezen voordat je een configuratie wijzigt.

MOBIKE wordt onderhandeld, niet aangenomen. Als de server het niet aanbiedt, moet de client opnieuw opbouwen, en dat is een feit dat je uit de SA-lijst of de log bevestigt in plaats van uit een draaiend wiel af te leiden.

Routevoorkeur bepaalt het pad, niet het Wi-Fi-pictogram

Met beide interfaces omhoog kiest de kernel op metriek en prefixlengte. ip route show default somt de kandidaten op en ip route get 203.0.113.10 beslecht de werkelijke beslissing, inclusief het bronadres. Een bedrade standaardroute op metriek 100 en een draadloze op 600 betekenen dat het eindpunt verschuift op het moment dat de kabel zit, terwijl elke toepassing die eerder een socket opende zijn oude bron houdt.

Windows doet hetzelfde met automatische interfacemetrieken, beïnvloed door de linksnelheid. Get-NetRoute -DestinationPrefix 0.0.0.0/0 sorteert de kandidaten en Find-NetRoute -RemoteIPAddress 203.0.113.10 geeft de interface en bron terug die de stack zou kiezen. Een client die zijn buitenste socket aan één interface bindt, blijft die gebruiken nadat de metriek omklapt; dat is een bindingsbeslissing, geen routeringsfout.

Android maakt de splitsing zichtbaar: ConnectivityManager meldt beschikbare netwerken en een aparte standaard, en een VPN-app die een socket aan een Network-object bindt, houdt die binding tot hij opnieuw bindt. Op macOS scutil --nwi drukt de primaire interface en de volgorde af die het systeem zou gebruiken.

DNS, MTU en IPv6 verschuiven mee met de aansluiting

Een nieuwe aansluiting brengt nieuwe resolvers. Met systemd-resolved is DNS per link, resolvectl status toont welke link een naam beantwoordt, en een gastnetwerk dat zijn eigen resolver uitdeelt, kan de door de tunnel geduwde DNS ongebruikt laten tot de link weer de voorkeur krijgt. Een captive portal maakt het erger: het eerste HTTPS-verzoek wordt door het portal beantwoord in plaats van het eindpunt, en de client registreert een dode server.

De MTU van het pad verandert ook. Ethernet en Wi-Fi dragen meestal 1500 bytes, PPPoE 1492, en mobiele links vaak minder. Een tunnel die een kleinere MTU erft, stokt op grote pakketten terwijl kleine verzoeken slagen, wat leest als een half kapotte verbinding. ping -M do -s 1472 203.0.113.10 stuurt een pakket van 1500 bytes met DF gezet; stilte betekent dat het pad kleiner is dan je aannam.

IPv6 is de andere helft. Een netwerk dat een nieuw prefix uitgeeft, verandert de bron die een dual-stack-client zou gebruiken, en een tunnel met alleen v4 laat v6-verkeer erbuiten tot het beleid bijtrekt. ip -6 route show default en ip -6 addr show beantwoorden of de nieuwe link überhaupt een v6-pad heeft.

Reproduceer de overgang in plaats van hem te beschrijven

Kies één onschuldig verzoek en voer dezelfde drie commando's aan weerszijden van de wijziging uit: ip -br addr, ip route show default, ip route get 203.0.113.10. Kijk dan of de tunnel nog pakketten verstuurt - tcpdump -ni any udp port 51820 voor WireGuard, de bijbehorende poort voor al het andere. Pakketten die van de oude bron vertrekken, betekenen een bindingsprobleem. Pakketten van de nieuwe bron zonder antwoord betekenen de verre kant of de NAT ertussen.

Noteer welke gebeurtenis samenviel met de eerste storing: link down, adreswijziging of wijziging van de standaardroute. Die wijzen op verschillende eigenaren - een client die opnieuw moet binden, een adres dat opnieuw moet worden verkregen, of een route die bij een configuratiebestand hoort en niet bij een permanente bypass-regel.

Voordat je het opgelost noemt, bevestig je dat het blok voor direct verkeer tijdens de onderbreking nog steeds staat en dat namen via de nieuwe aansluiting worden opgelost. Als de client na de wissel het oude eindpunt houdt, repareer dan eerst de roaming- of float-instelling. Als hij correct roamt en nog steeds geen antwoord krijgt, kijk dan naar de peer-identiteit van de server en de NAT op het pad, en houd beide netwerkcontexten in het verslag zodat de volgende persoon ze kan vergelijken.