Slik sjekker du om en Mesh Wi-Fi-satellitt bruker VPN-ruteren
Følg standardgatewayen, videresendingsmodusen til noden og tilstandstabellen til ruteren for å bevise om klientene til en Mesh-satellitt går gjennom VPN-et.
En satellitt som svarer på samme Wi-Fi-navn som basisruteren, sier nesten ingenting om hvor pakkene til klientene går. Noden er en radio og en bro til det motsatte er bevist. Det som avgjør utgangen, er standardgatewayen hver klient får, og videresendingsmodusen til noden foran den. Kjør disse fem sjekkene fra klienten og utover, og du har et svar du kan forsvare, i stedet for et inntrykk fra en hastighetstest.
Les gatewayen klienten faktisk fikk
På klienten skriver du ut rutetabellen og nabotabellen. Standardruten angir adressen som videresender trafikk; naboinnslaget angir MAC-adressen som eier den adressen. Bruk klienten, ikke enhetslisten til ruteren, fordi en enhetsliste viser tilknytninger, ikke ruter.
ip route show default
ip -6 route show default
ip neigh showWindows skriver de samme fakta i en annen form: ipconfig /all gir standardgatewayen og arp -a gir MAC-adressen. På macOS dekker route -n get default og arp -an det samme.
Sammenlign den gatewayen med to adresser du allerede kjenner: LAN-adressen til basisruteren og administrasjonsadressen til satellitten. Er gatewayen LAN-adressen til ruteren, er klienten broet til ruteren, og policyen til ruteren for det nettet gjelder uendret. Er gatewayen adressen til satellitten, ruter satellitten, og ruteren ser aldri pakkene til klienten som LAN-trafikk; avgjørelsen må tas på noden, ellers tas den ikke.
Bekreft hvilken modus noden egentlig står i
Mesh-produkter gjenbruker tre ord for ulik oppførsel, så stol mer på pakkeveien enn på etiketten i appen. Bro- eller aksesspunktmodus videresender rammer. Rutermodus avslutter et subnett og kjører DHCP. Gjestemodus plasserer vanligvis klienter i et eget VLAN med egne regler. En node i rutermodus bak en annen ruter er en dobbel NAT, og klientene når VPN-ruteren allerede oversatt, noe som undergraver policy som matcher på kildeadressen.
| 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 |
For å fastslå MAC-adressen leser du etiketten på noden og sammenligner den med ip neigh. Produsenter trykker basis-MAC-en og utleder MAC-adressene for hver radio ved å øke en byte, så det siste heksadesimale sifferet varierer; sammenlign prefikset i stedet for hele adressen. Tilhører gateway-MAC-en LAN-grensesnittet til ruteren, ruter noden ikke for den klienten.
Bevis utgangen på ruteren, ikke med en hastighetstest
Tilstanden på ruterens side er det eneste stedet som viser oversettelsen. På OpenWrt lister du opp policyreglene og rutetabellene og bekrefter deretter at tunnelen har et nylig handshake:
ip rule show
ip route show table all | grep default
wg showPå pfSense eller OPNsense ligger de samme bevisene i pfctl -sr for regler, pfctl -ss for aktive tilstander og WireGuard-statussiden for peer-tellere, i tråd med WireGuard-klientdokumentasjonen. Filtrer tilstandstabellen på adressen til klienten. Viser tilstanden klienten oversatt til tunneladressen, er trafikken i tunnelen; viser den WAN-adressen, er den ikke, uansett hva merket på dashbordet sier.
En traceroute fra klienten legger til ett faktum som tilstandstabellen ikke kan gi: første hopp. Er første hopp LAN-adressen til ruteren, nådde klienten ruteren direkte. Er det adressen til noden fulgt av enda et privat hopp, er du på et rutet segment, og det andre hoppet er enheten som må holde policyen.
Sjekk hva noden deler ut i tillegg til en adresse
DHCP-opsjoner reiser med lease-avtalen, så en node med egen DHCP kan også dele ut egen DNS og egne IPv6-ruterannonser. En klient kan derfor gå ut gjennom tunnelen og likevel sende spørringer til en resolver på noden, eller få en global IPv6-adresse som tunnelpolicyen aldri dekker. Skriv ut begge på klienten:
cat /etc/resolv.conf
ip -6 addr show scope globalEr resolveren noden, og videresender noden til ruteren, følger DNS tunnelen. Slår noden opp lokalt eller peker på resolveren til leverandøren, forlater spørringene tunnelen selv når HTTP ikke gjør det. IPv6 fortjener samme test: en global adresse pluss en standardrute som omgår tunnelen er en lekkasje, og Mesh-fastvaren lar ofte IPv6 stå på mens VPN-policyen bare dekker IPv4.
Bryt tunnelen med vilje, og skriv ned resultatet
Ta ned tunnelen og se på en klient som er knyttet til den noden, ikke en klient ved siden av ruteren. ping og en curl med kort tidsavbrudd er nok; spørsmålet er om trafikken stopper eller faller tilbake til WAN. Stopp tunnelen med ruterens egen tjenestekommando, for eksempel wg-quick down wg0 eller stopp av OpenVPN-tjenesten, og hold testen kort.
Virker klienten fortsatt, feiler noden eller ruteren åpent for det segmentet, og meshet har stille opphevet kill switch. Få tunnelen tilbake, bekreft at handshake-telleren har flyttet seg, og gjenta tilstandstabellsjekken fra tredje trinn.
Noter én rad per node: etikett, SSID, gatewayadresse, MAC-prefiks, utgang bekreftet ja eller nei, IPv6 dekket og oppførsel med tunnelen nede. Roaming er der svaret endrer seg, så test rommene du faktisk bruker. Når én rad ikke stemmer med de andre, er den noden den som skal undersøkes, og rettelsen hører til enheten som eier gatewayen i den raden.