Sådan kontrollerer du, om en Mesh Wi-Fi-satellit bruger VPN-routeren
Følg standardgatewayen, nodens videresendelsestilstand og routerens tilstandstabel for at bevise, om en Mesh-satellits klienter kører gennem VPN’en.
En satellit, der svarer på samme Wi-Fi-navn som basisrouteren, fortæller næsten intet om, hvor dens klienters pakker ender. Noden er en radio og en bro, indtil det modsatte er bevist. Det, der afgør udgangen, er den standardgateway, hver klient får, og videresendelsestilstanden på noden foran den. Kør disse fem kontroller fra klienten og udad, og du har et svar, du kan forsvare, i stedet for et indtryk fra en hastighedstest.
Læs den gateway, klienten faktisk fik
På klienten udskrives rutetabellen og nabo-tabellen. Standardruten angiver den adresse, der videresender trafik; naboindgangen angiver den MAC, der ejer adressen. Brug klienten og ikke routerens enhedsliste, fordi en enhedsliste viser tilknytninger, ikke ruter.
ip route show default
ip -6 route show default
ip neigh showWindows viser de samme fakta i en anden form: ipconfig /all giver standardgatewayen, og arp -a giver MAC-adressen. På macOS dækker route -n get default og arp -an det samme.
Sammenlign den gateway med to adresser, du allerede kender: basisrouterens LAN-adresse og satellittens administrationsadresse. Er gatewayen routerens LAN-adresse, er klienten broet til routeren, og routerens politik for det LAN gælder uændret. Er gatewayen satellittens adresse, router satellitten, og routeren ser aldrig klientens pakker som LAN-trafik; beslutningen skal træffes på noden, ellers træffes den ikke.
Bekræft, hvilken tilstand noden reelt er i
Mesh-produkter genbruger tre ord til forskellig adfærd, så stol mere på pakkestien end på etiketten i appen. Bro- eller access point-tilstand videresender frames. Routertilstand afslutter et subnet og kører DHCP. Gæstetilstand placerer normalt klienter i et separat VLAN med egne regler. En node i routertilstand bag en anden router er en dobbelt NAT, og dens klienter når VPN-routeren allerede oversat, hvilket underminerer politik, der 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 at fastslå MAC-adressen læses etiketten på noden og sammenlignes med ip neigh. Producenter trykker basis-MAC’en og udleder MAC’erne for hver radio ved at øge en byte, så det sidste hexadecimale ciffer afviger; sammenlign præfikset i stedet for hele adressen. Hører gateway-MAC’en til routerens LAN-interface, router noden ikke for den klient.
Bevis udgangen på routeren, ikke med en hastighedstest
Tilstanden på routersiden er det eneste sted, der viser oversættelsen. På OpenWrt listes politikreglerne og rutetabellerne, og derefter bekræftes det, at tunnelen har et nyligt handshake:
ip rule show
ip route show table all | grep default
wg showPå pfSense eller OPNsense findes de samme beviser i pfctl -sr for regler, pfctl -ss for aktive tilstande og WireGuard-statusiden for peer-tællere, ifølge WireGuard-klientdokumentationen. Filtrer tilstandstabellen på klientens adresse. Viser tilstanden klienten oversat til tunneladressen, er trafikken i tunnelen; viser den WAN-adressen, er den ikke, uanset hvad badget på dashboards viser.
En traceroute fra klienten tilføjer et faktum, som tilstandstabellen ikke kan give: det første hop. Er første hop routerens LAN-adresse, nåede klienten routeren direkte. Er det nodens adresse efterfulgt af endnu et privat hop, er du på et routet segment, og det andet hop er den enhed, der skal holde politikken.
Kontroller, hvad noden uddeler ud over en adresse
DHCP-optioner rejser med leasen, så en node med egen DHCP kan også uddele egen DNS og egne IPv6-routerannoncer. En klient kan derfor gå ud gennem tunnelen og stadig sende forespørgsler til en resolver på noden eller få en global IPv6-adresse, som tunnelpolitikken aldrig dækker. Udskriv begge på klienten:
cat /etc/resolv.conf
ip -6 addr show scope globalEr resolveren noden, og videresender noden til routeren, følger DNS tunnelen. Slår noden op lokalt eller peger på udbyderens resolver, forlader forespørgslerne tunnelen, selv når HTTP ikke gør. IPv6 fortjener samme test: en global adresse plus en standardrute, der omgår tunnelen, er en lækage, og Mesh-firmware lader ofte IPv6 være tændt, mens VPN-politikken kun dækker IPv4.
Bryd tunnelen med vilje, og skriv resultatet ned
Tag tunnelen ned, og se på en klient, der er knyttet til den node, ikke en klient ved siden af routeren. ping og en curl med kort timeout er nok; spørgsmålet er, om trafikken stopper eller falder tilbage til WAN. Stop tunnelen med routerens egen servicekommando, for eksempel wg-quick down wg0 eller OpenVPN-tjenestens stop, og hold testen kort.
Virker klienten stadig, fejler noden eller routeren åbent for det segment, og meshet har stille ophævet kill switch. Bring tunnelen tilbage, bekræft at handshake-tælleren har flyttet sig, og gentag tilstandstabelkontrollen fra tredje trin.
Notér en række per node: etiket, SSID, gatewayadresse, MAC-præfiks, udgang bekræftet ja eller nej, IPv6 dækket og adfærd med tunnelen nede. Roaming er der, hvor svaret ændrer sig, så test de rum, du faktisk bruger. Når en række ikke stemmer med de andre, er den node den, der skal undersøges, og rettelsen hører til den enhed, der ejer rækkens gateway.