Hoe u controleert of een mesh-Wi-Fi-satelliet via de VPN-router gaat

Een satelliet die onder dezelfde Wi-Fi-naam antwoordt als de basisrouter zegt bijna niets over waar de pakketten van zijn clients naartoe gaan. Het knooppunt is een radio en een bridge tot het tegendeel bewezen is. Wat de uitgang bepaalt, is de standaardgateway die elke client krijgt en de doorstuurmodus van het knooppunt ervoor. Voer deze vijf controles van de client naar buiten uit, en u hebt een verdedigbaar antwoord in plaats van een indruk uit een snelheidstest.

Lees de gateway die de client werkelijk heeft gekregen

Print op de client de routetabel en de naburentabel. De standaardroute noemt het adres dat verkeer doorstuurt; de naburige vermelding noemt de MAC die bij dat adres hoort. Gebruik de client, niet de apparatenlijst van de router, want een apparatenlijst toont koppelingen, geen paden.

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

Windows print dezelfde feiten in een andere vorm: ipconfig /all geeft de standaardgateway en arp -a geeft de MAC. Op macOS dekken route -n get default en arp -an hetzelfde terrein.

Vergelijk die gateway met twee adressen die u al kent: het LAN-adres van de basisrouter en het beheeradres van de satelliet. Is de gateway het LAN-adres van de router, dan is de client gebrugd naar de router en geldt het beleid van de router voor dat LAN onveranderd. Is de gateway het adres van de satelliet, dan routeert de satelliet, en de router ziet de pakketten van de client nooit als LAN-verkeer; de beslissing moet op het knooppunt vallen, anders valt ze niet.

Controleer in welke modus het knooppunt werkelijk staat

Mesh-producten hergebruiken drie woorden voor verschillend gedrag, dus vertrouw het pakketpad meer dan het label in de app. Bridge- of accesspointmodus stuurt frames door. Routermode beëindigt een subnet en draait DHCP. Gastmodus zet clients meestal in een apart VLAN met eigen regels. Een knooppunt in routermode achter een andere router is een dubbele NAT, en zijn clients komen al vertaald bij de VPN-router aan, wat beleid op basis van het bronadres ondermijnt.

Om de MAC vast te leggen, leest u het label op het knooppunt en vergelijkt u het met ip neigh. Fabrikanten drukken de basis-MAC en leiden de MAC’s per radio af door een byte te verhogen, dus het laatste hexadecimale cijfer verschilt; vergelijk het voorvoegsel in plaats van het hele adres. Hoort de gateway-MAC bij de LAN-interface van de router, dan routeert het knooppunt niet voor die client.

Bewijs de uitgang op de router, niet met een snelheidstest

De status aan de routerkant is de enige plek die de vertaling toont. Lijst op OpenWrt de beleidsregels en routetabellen op en bevestig daarna dat de tunnel een recente handshake heeft:

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

Op pfSense of OPNsense staan dezelfde bewijzen in pfctl -sr voor regels, pfctl -ss voor actieve statussen en de WireGuard-statuspagina voor peer-tellers, volgens de WireGuard-clientdocumentatie. Filter de statustabel op het adres van de client. Toont de status de client vertaald naar het tunneladres, dan zit het verkeer in de tunnel; toont hij het WAN-adres, dan niet, wat de badge op het dashboard ook zegt.

Een traceroute vanaf de client voegt één feit toe dat de statustabel niet kan geven: de eerste hop. Is de eerste hop het LAN-adres van de router, dan heeft de client de router rechtstreeks bereikt. Is het het adres van het knooppunt gevolgd door nog een private hop, dan zit u op een gerouteerd segment, en die tweede hop is het apparaat dat het beleid moet dragen.

Controleer wat het knooppunt nog meer uitgeeft dan een adres

DHCP-opties reizen mee met de lease, dus een knooppunt met eigen DHCP kan ook eigen DNS en eigen IPv6-routeradvertenties uitdelen. Een client kan daardoor door de tunnel naar buiten gaan en toch query’s naar een resolver op het knooppunt sturen, of een wereldwijd IPv6-adres krijgen dat het tunnelbeleid nooit dekt. Print beide op de client:

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

Is de resolver het knooppunt en stuurt het knooppunt door naar de router, dan volgt DNS de tunnel. Lost het knooppunt lokaal op of wijst het naar de resolver van de provider, dan verlaten de query’s de tunnel zelfs wanneer HTTP dat niet doet. IPv6 verdient dezelfde test: een wereldwijd adres plus een standaardroute die de tunnel omzeilt is een lek, en mesh-firmware laat IPv6 vaak aan staan terwijl het VPN-beleid alleen IPv4 dekt.

Breek de tunnel expres en schrijf de uitkomst op

Haal de tunnel neer en kijk naar een client die met dat knooppunt is verbonden, niet naar een client naast de router. ping en een curl met korte time-out zijn genoeg; de vraag is of verkeer stopt of terugvalt op de WAN. Stop de tunnel met het servicecommando van de router zelf, bijvoorbeeld wg-quick down wg0 of het stoppen van de OpenVPN-service, en houd de test kort.

Blijft de client werken, dan faalt het knooppunt of de router open voor dat segment, en heeft de mesh de kill switch stilletjes ongedaan gemaakt. Breng de tunnel terug, bevestig dat de handshake-teller is opgeschoven en herhaal de statustabelcontrole uit de derde stap.

Noteer één regel per knooppunt: label, SSID, gatewayadres, MAC-voorvoegsel, uitgang bevestigd ja of nee, IPv6 gedekt en gedrag met de tunnel neer. Roaming is waar het antwoord verandert, dus test de kamers die u echt gebruikt. Als één regel afwijkt van de rest, is dat knooppunt het onderzoeksobject, en de oplossing hoort bij het apparaat dat de gateway van die regel bezit.