Slik sjekkar du om ein Mesh Wi-Fi-satellitt brukar VPN-rutaren

Ein satellitt som svarar på same Wi-Fi-namn som basisrutaren, seier nesten ingenting om kvar pakkane til klientane går. Noden er ein radio og ei bru til det motsette er bevist. Det som avgjer utgangen, er standardgatewayen kvar klient får, og vidaresendingsmodusen til noden framfor han. Køyr desse fem sjekkane frå klienten og utover, og du har eit svar du kan forsvara, i staden for eit inntrykk frå ein hastigheitstest.

Les gatewayen klienten faktisk fekk

På klienten skriv du ut rutetabellen og nabotabellen. Standardruta angir adressa som vidaresender trafikk; naboinnslaget angir MAC-adressa som eig den adressa. Bruk klienten, ikkje eininglista til rutaren, fordi ei einingliste viser tilknytingar, ikkje ruter.

ip route show default
ip -6 route show default
ip neigh show

Windows skriv dei same fakta i ei anna form: ipconfig /all gir standardgatewayen og arp -a gir MAC-adressa. På macOS dekkjer route -n get default og arp -an det same.

Samanlikn den gatewayen med to adresser du allereie kjenner: LAN-adressa til basisrutaren og administrasjonsadressa til satellitten. Er gatewayen LAN-adressa til rutaren, er klienten brua til rutaren, og policyen til rutaren for det nettet gjeld uendra. Er gatewayen adressa til satellitten, rutar satellitten, og rutaren ser aldri pakkane til klienten som LAN-trafikk; avgjerda må takast på noden, elles blir ho ikkje teken.

Stadfest kva modus noden eigentleg står i

Mesh-produkt brukar tre ord om att for ulik åtferd, så stol meir på pakkevegen enn på etiketten i appen. Bru- eller aksesspunktmodus vidaresender rammer. Rutarmodus avsluttar eit subnett og køyrer DHCP. Gjestemodus plasserer vanlegvis klientar i eit eige VLAN med eigne reglar. Ein node i rutarmodus bak ein annan rutar er ein dobbel NAT, og klientane når VPN-rutaren allereie omsette, noko som undergrev policy som matchar på kjeldeadressa.

For å fastslå MAC-adressa les du etiketten på noden og samanliknar han med ip neigh. Produsentar trykkjer basis-MAC-en og leier ut MAC-adressene for kvar radio ved å auke ein byte, så det siste heksadesimale sifferet varierer; samanlikn prefikset i staden for heile adressa. Høyrer gateway-MAC-en til LAN-grensesnittet til rutaren, rutar noden ikkje for den klienten.

Bevis utgangen på rutaren, ikkje med ein hastigheitstest

Tilstanden på rutarsida er den einaste staden som viser omsetjinga. På OpenWrt listar du opp policyreglane og rutetabellane og stadfestar deretter at tunnelen har eit nyleg handshake:

ip rule show
ip route show table all | grep default
wg show

På pfSense eller OPNsense ligg dei same prova i pfctl -sr for reglar, pfctl -ss for aktive tilstandar og WireGuard-statussida for peer-teljarar, i tråd med WireGuard-klientdokumentasjonen. Filtrer tilstandstabellen på adressa til klienten. Viser tilstanden klienten omsett til tunneladressa, er trafikken i tunnelen; viser han WAN-adressa, er han ikkje, uansett kva merket på dashbordet seier.

Ein traceroute frå klienten legg til eitt faktum som tilstandstabellen ikkje kan gi: første hopp. Er første hopp LAN-adressa til rutaren, nådde klienten rutaren direkte. Er det adressa til noden følgd av endå eit privat hopp, er du på eit ruta segment, og det andre hoppet er eininga som må halde policyen.

Sjekk kva noden deler ut i tillegg til ei adresse

DHCP-opsjonar reiser med lease-avtalen, så ein node med eigen DHCP kan også dele ut eigen DNS og eigne IPv6-rutarannonsar. Ein klient kan derfor gå ut gjennom tunnelen og likevel sende spørjingar til ein resolver på noden, eller få ei global IPv6-adresse som tunnelpolicyen aldri dekkjer. Skriv ut begge på klienten:

cat /etc/resolv.conf
ip -6 addr show scope global

Er resolveren noden, og vidaresender noden til rutaren, følgjer DNS tunnelen. Slår noden opp lokalt eller peikar på resolveren til leverandøren, forlèt spørjingane tunnelen sjølv når HTTP ikkje gjer det. IPv6 fortener same test: ei global adresse pluss ei standardrute som omgår tunnelen er ein lekkasje, og Mesh-fastvaren let ofte IPv6 stå på medan VPN-policyen berre dekkjer IPv4.

Bryt tunnelen med vilje, og skriv ned resultatet

Ta ned tunnelen og sjå på ein klient som er knytt til den noden, ikkje ein klient ved sida av rutaren. ping og ein curl med kort tidsavbrot er nok; spørsmålet er om trafikken stoppar eller fell tilbake til WAN. Stopp tunnelen med rutaren si eiga tenestekommando, til dømes wg-quick down wg0 eller stopp av OpenVPN-tenesta, og hald testen kort.

Verker klienten framleis, feilar noden eller rutaren ope for det segmentet, og meshet har stille oppheva kill switch. Få tunnelen tilbake, stadfest at handshake-teljaren har flytta seg, og gjenta tilstandstabellsjekken frå tredje trinn.

Noter éi rad per node: etikett, SSID, gatewayadresse, MAC-prefiks, utgang stadfesta ja eller nei, IPv6 dekt og åtferd med tunnelen nede. Roaming er der svaret endrar seg, så test romma du faktisk brukar. Når éi rad ikkje stemmer med dei andre, er den noden den som skal undersøkjast, og rettinga høyrer til eininga som eig gatewayen i den rada.