Miért szakad meg a VPN, amikor a Wi-Fi vált vagy Ethernetet dugsz be

Két dolgot egyetlen hibaként jelentenek: a laptop átkerült egy másik Wi-Fi-hálózatra, vagy kábelt dugtak be, miközben a Wi-Fi tovább élt. A kliens továbbra is azt mondja, csatlakozva, az ikon egészségesnek látszik, az alagút pedig semmit nem szállít. A felszín alatt csak három állapotdarab mozdulhat el - a kapcsolat, a helyi cím, az alapértelmezett útvonal - és hogy melyik mozdult el, eldönti, magától helyreáll-e az alagút, vagy újracsatlakozás kell. Ebben a sorrendben ellenőrzöm őket, mert a fiókbeállítások módosítása még soha nem javított egyiket sem.

A kapcsolat, a cím és az útvonal egymástól függetlenül mozdul

A hozzáférési pontok közötti barangolás ugyanazon a hálózaton általában L2-esemény. A rádió újra asszociál, az interfész megtartja a címét és az átjáróját, és semmi sem változik, amitől az alagút függ, ezért egy nagy irodán átsétálni néha észrevétlen marad. Egy másik SSID-hez csatlakozni nem ez: a régi interfész lemehet, a DHCP új címet, új átjárót és új feloldókat ad, és a külső folyam, amelyet az alagút használt, megszűnik.

Az Ethernet hozzáad egy harmadik formát. A Wi-Fi soha nem esik ki, tehát egyáltalán nem indul kapcsolatesemény, mégis megjelenik a vezetékes interfész a saját címével, és gyakran megnyeri az alapértelmezett útvonalat a metrika alapján. Az alagút tovább fut egy olyan úton, amely már nem előnyös, vagy a kliens a socketjét ahhoz a vezeték nélküli hálózathoz szögezi, amelyen elindult. A böngészőből mindkettő ugyanúgy néz ki: az oldalak abban a pillanatban megakadnak, amikor a kábel bekattan.

Tehát az első kérdés nem az, hogy megváltozott-e a Wi-Fi. Hanem az, hogy megváltozott-e a cím, amelyhez kötve vagy, vagy az útvonal a végpontig, miközben az alagút futott.

A külső socket egy olyan címhez van szögelve, amely épp most tűnt el

Minden alagút külső folyam: egy helyi cím és port beszél a szerver címével és portjával. Linuxon ez egy UDP-socket, a régi forráshoz kötve; amikor a címet tartó interfészt eltávolítják, a küldések vagy EADDRNOTAVAIL hibával meghiúsulnak, vagy az új interfészen mennek ki olyan forrással, amelyet a szerver még soha nem látott.

A túloldal a saját rögzítését tartja. Egy MOBIKE nélküli IKEv2 SA-t a címpár azonosít, és egy OpenVPN munkamenet ahhoz a peer-címhez van kötve, amelyet megtanult, a NAT-leképezés pedig ahhoz a magáncímhez, porthoz és nyilvános címhez tartozik, amelyek létrehozták. Menj egy másik NAT mögé, és minden válasz egy olyan leképezésre megy, amely már nem létezik. A gépeden semmi sincs rosszul beállítva; az ötös címkészlet egy olyan hálózatra mutat, amelyet elhagytál.

Olvasd el az állapotot, mielőtt elméleteket gyártasz:

• ss -unp megmutatja a helyi címet és portot, amelyet az egyes alagút-socketek valóban tartanak.
• ip route get 203.0.113.10 kiírja a forráscímet és az eszközt, amelyet a kernel most a végpont felé használna.
• wg show wg0 endpoints, swanctl --list-sas vagy a kliens naplója megmutatja a peer-címet, amellyel a túloldal szerint beszél.

Ha a socket címe és az útvonalkeresés nem egyezik, megtaláltad a törést, és semmilyen hitelesítőadat-módosítás nem fog hozzányúlni.

Mit tesz az egyes protokollok egy új forráscímmel

A kliensek különböző mértékben szívják fel a változást, és a táblázat az, amihez a kliens konfigurációját hasonlítom, ahelyett hogy az újracsatlakozási viselkedésből találgatnék.

A WireGuard barangolási szabálya csak egy irányban működik: a kliensnek először az új címről kell küldenie. Egy még a régi interfészhez kötött socket ezt soha nem teszi, ezért az alagút élőnek látszhat, miközben a kézfogás-időzítője öregszik. protokoll leírása pontosan megadja a végpont frissítésének feltételét, és érdemes elolvasni, mielőtt bármilyen konfigurációt módosítasz.

A MOBIKE-t megtárgyalják, nem feltételezik. Ha a szerver nem kínálja, a kliensnek újra kell építenie, és ez olyan tény, amelyet az SA-listából vagy a naplóból erősítesz meg, nem pedig egy forgó kerékből következtetsz.

Az útvonalpreferencia dönti el az utat, nem a Wi-Fi ikon

Ha mindkét interfész fel van, a kernel metrika és előtaghossz szerint választ. ip route show default felsorolja a jelölteket, és a ip route get 203.0.113.10 feloldja a tényleges döntést, a forráscímmel együtt. Egy vezetékes alapértelmezett útvonal 100-as metrikával és egy vezeték nélküli 600-assal azt jelenti, hogy a végpont abban a pillanatban elmozdul, amikor a kábel beül, miközben minden alkalmazás, amely korábban socketet nyitott, megtartja a régi forrását.

A Windows ugyanezt teszi automatikus interfész-metrikákkal, amelyeket a kapcsolat sebessége torzít. Get-NetRoute -DestinationPrefix 0.0.0.0/0 rendezi a jelölteket, és a Find-NetRoute -RemoteIPAddress 203.0.113.10 visszaadja azt az interfészt és forrást, amelyet a verem választana. Az a kliens, amely a külső socketjét egy interfészhez köti, tovább használja azt a metrika átbillenése után is; ez kötési döntés, nem útvonalválasztási hiba.

Az Android láthatóvá teszi a szétválást: a ConnectivityManager jelenti az elérhető hálózatokat és egy külön alapértelmezettet, és egy VPN-alkalmazás, amely socketet köt egy Network objektumhoz, megtartja ezt a kötést, amíg újra nem köti. A macOS-en a scutil --nwi kiírja az elsődleges interfészt és azt a sorrendet, amelyet a rendszer használna.

A DNS, az MTU és az IPv6 a csatlakozással együtt mozdul

Egy új csatlakozás új feloldókat hoz. A systemd-resolvednél a DNS kapcsolatonkénti, a resolvectl status megmutatja, melyik kapcsolat válaszol egy névre, és egy vendéghálózat, amely a saját feloldóját osztja ki, használatlanul hagyhatja az alagút által áttolt DNS-t, amíg a kapcsolat újra előnyössé nem válik. Egy befogó portál ront a helyzeten: az első HTTPS-kérésre a portál válaszol a végpont helyett, és a kliens halott szervert jegyez fel.

Az útvonal MTU-ja is változik. Az Ethernet és a Wi-Fi általában 1500 bájtot visz, a PPPoE 1492-t, a mobil kapcsolatok pedig gyakran kevesebbet. Egy alagút, amely kisebb MTU-t örököl, megakad a nagy csomagokon, miközben a kis kérések átmennek, ami félig törött kapcsolatnak olvasható. ping -M do -s 1472 203.0.113.10 1500 bájtos csomagot küld DF-fel; a csend azt jelenti, hogy az út kisebb, mint feltételezted.

Az IPv6 a másik fele. Egy hálózat, amely új előtagot oszt ki, megváltoztatja a forrást, amelyet egy kettős veremű kliens használna, és egy csak v4-es alagút a v6-forgalmat kívül hagyja, amíg a szabályzat be nem ér. ip -6 route show default és a ip -6 addr show megválaszolja, van-e egyáltalán v6-os út az új kapcsolaton.

Reprodukáld az átmenetet, ahelyett hogy leírnád

Válassz egy ártalmatlan kérést, és futtasd ugyanazt a három parancsot a változás mindkét oldalán: ip -br addr, ip route show default, ip route get 203.0.113.10. Aztán figyeld, hogy az alagút még mindig küld-e csomagokat - tcpdump -ni any udp port 51820 a WireGuardnál, a megfelelő port bármi másnál. A régi forrásból kilépő csomagok kötési problémát jelentenek. Az új forrásból válasz nélkül kilépő csomagok a túloldalt vagy a közbeeső NAT-ot jelentik.

Jegyezd fel, melyik esemény esett egybe az első hibával: kapcsolat le, címváltozás vagy az alapértelmezett útvonal változása. Ezek különböző felelősökre mutatnak - egy kliensre, amelyet újra kell kötni, egy címre, amelyet újra kell szerezni, vagy egy útvonalra, amely konfigurációs fájlhoz tartozik, és nem állandó megkerülési szabályhoz.

Mielőtt javítottnak neveznéd, erősítsd meg, hogy a közvetlen forgalom blokkja a rés alatt is tart, és hogy a nevek az új csatlakozáson keresztül oldódnak fel. Ha a kliens a váltás után a régi végpontot tartja, először a barangolás vagy a float beállítását javítsd. Ha helyesen barangol és mégsem kap választ, nézd meg a szerver peer-identitását és az útvonalon lévő NAT-ot, és tartsd meg mindkét hálózati kontextust a leírásban, hogy a következő ember össze tudja hasonlítani őket.