Så kontrollerar du om en Mesh Wi-Fi-satellit använder VPN-routern
Följ standardgatewayen, nodens vidarebefordringsläge och routerns tillståndstabell för att bevisa om en Mesh-satellits klienter går genom VPN:et.
En satellit som svarar på samma Wi-Fi-namn som basroutern säger nästan ingenting om vart dess klienters paket tar vägen. Noden är en radio och en brygga tills motsatsen är bevisad. Det som avgör utgången är den standardgateway varje klient får och vidarebefordringsläget hos noden framför den. Gör dessa fem kontroller från klienten och utåt, så har du ett svar du kan försvara i stället för ett intryck från ett hastighetstest.
Läs den gateway som klienten faktiskt fick
På klienten skrivs routingtabellen och grannatabellen ut. Standardrutten anger den adress som vidarebefordrar trafik; grannposten anger det MAC som äger adressen. Använd klienten och inte routerns enhetslista, eftersom en enhetslista visar associationer, inte vägar.
ip route show default
ip -6 route show default
ip neigh showWindows skriver samma fakta i en annan form: ipconfig /all ger standardgatewayen och arp -a ger MAC-adressen. På macOS täcker route -n get default och arp -an samma sak.
Jämför den gatewayen med två adresser du redan känner: basrouterns LAN-adress och satellitens administrationsadress. Är gatewayen routerns LAN-adress är klienten bryggad till routern, och routerns policy för det nätet gäller oförändrat. Är gatewayen satellitens adress routar satelliten, och routern ser aldrig klientens paket som LAN-trafik; beslutet måste fattas på noden, annars fattas det inte.
Bekräfta vilket läge noden verkligen är i
Mesh-produkter återanvänder tre ord för olika beteenden, så lita mer på paketvägen än på etiketten i appen. Brygg- eller åtkomstpunktsläge vidarebefordrar ramar. Routerläge avslutar ett subnät och kör DHCP. Gästläge placerar oftast klienter i ett separat VLAN med egna regler. En nod i routerläge bakom en annan router är en dubbel NAT, och dess klienter når VPN-routern redan översatta, vilket undergräver policy som matchar på källadressen.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
För att fastställa MAC-adressen läser du etiketten på noden och jämför den med ip neigh. Tillverkare trycker bas-MAC:en och härleder MAC-adresserna för varje radio genom att öka en byte, så den sista hexadecimala siffran skiljer sig; jämför prefixet i stället för hela adressen. Tillhör gatewayens MAC routerns LAN-gränssnitt routar noden inte för den klienten.
Bevisa utgången på routern, inte med ett hastighetstest
Tillståndet på routersidan är den enda platsen som visar översättningen. På OpenWrt listar du policyreglerna och routingtabellerna och bekräftar sedan att tunneln har ett färskt handshake:
ip rule show
ip route show table all | grep default
wg showPå pfSense eller OPNsense finns samma bevis i pfctl -sr för regler, pfctl -ss för aktiva tillstånd och WireGuard-statussidan för peer-räknare, enligt WireGuard-klientdokumentationen. Filtrera tillståndstabellen på klientens adress. Visar tillståndet klienten översatt till tunneladressen är trafiken i tunneln; visar det WAN-adressen är den inte, vad än märket på instrumentpanelen säger.
En traceroute från klienten lägger till ett faktum som tillståndstabellen inte kan ge: första hoppet. Är första hoppet routerns LAN-adress nådde klienten routern direkt. Är det nodens adress följd av ännu ett privat hopp befinner du dig på ett routat segment, och det andra hoppet är den enhet som måste hålla policyn.
Kontrollera vad noden delar ut förutom en adress
DHCP-optioner följer med lånet, så en nod med egen DHCP kan också dela ut egen DNS och egna IPv6-routerannonser. En klient kan därför gå ut genom tunneln och ändå skicka frågor till en resolver på noden, eller få en global IPv6-adress som tunnelpolicyn aldrig täcker. Skriv ut båda på klienten:
cat /etc/resolv.conf
ip -6 addr show scope globalÄr resolvern noden och vidarebefordrar noden till routern följer DNS tunneln. Slår noden upp lokalt eller pekar på leverantörens resolver lämnar frågorna tunneln även när HTTP inte gör det. IPv6 förtjänar samma test: en global adress plus en standardrutt som kringgår tunneln är en läcka, och Mesh-firmware lämnar ofta IPv6 på medan VPN-policyn bara täcker IPv4.
Bryt tunneln med avsikt och skriv ned resultatet
Ta ned tunneln och titta på en klient som är ansluten till den noden, inte en klient bredvid routern. ping och en curl med kort tidsgräns räcker; frågan är om trafiken stannar eller faller tillbaka till WAN. Stoppa tunneln med routerns eget servicekommando, till exempel wg-quick down wg0 eller OpenVPN-tjänstens stopp, och håll testet kort.
Fungerar klienten fortfarande misslyckas noden eller routern öppet för det segmentet, och meshet har tyst upphävt kill switch. Ta tillbaka tunneln, bekräfta att handshake-räknaren har rört sig och upprepa tillståndstabellkontrollen från tredje steget.
Anteckna en rad per nod: etikett, SSID, gatewayadress, MAC-prefix, utgång bekräftad ja eller nej, IPv6 täckt och beteende med tunneln nere. Roaming är där svaret ändras, så testa de rum du faktiskt använder. När en rad inte stämmer med de andra är den noden den som ska undersökas, och rättelsen hör hemma på den enhet som äger radens gateway.