’n Satelliet wat op dieselfde Wi-Fi-naam as die basisroeteerder antwoord, sê byna niks oor waar sy kliënte se pakkette heen gaan nie. Die node is ’n radio en ’n brug tot die teendeel bewys word. Wat die uitgang bepaal, is die verstekpoort wat elke kliënt kry en die deurstiurmodus van die node daarvoor. Doen hierdie vyf kontroles van die kliënt na buite, en jy het ’n antwoord wat jy kan verdedig, nie ’n indruk uit ’n spoedtoets nie.

Lees die poort wat die kliënt werklik gekry het

Druk op die kliënt die roetetabel en die buurtabel. Die verstekroete noem die adres wat verkeer deurstuur; die buurinskrywing noem die MAC wat daardie adres besit. Gebruik die kliënt, nie die roeteerder se toestellys nie, want ’n toestellys wys assosiasies, nie paaie nie.

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

Windows druk dieselfde feite in ’n ander vorm: ipconfig /all gee die verstekpoort en arp -a gee die MAC. Op macOS dek route -n get default en arp -an dieselfde grond.

Vergelyk daardie poort met twee adresse wat jy al ken: die LAN-adres van die basisroeteerder en die bestuursadres van die satelliet. As die poort die roeteerder se LAN-adres is, is die kliënt via ’n brug aan die roeteerder gekoppel en geld die roeteerder se beleid vir daardie netwerk onveranderd. As die poort die satelliet se adres is, roeteer die satelliet, en die roeteerder sien nooit die kliënt se pakkette as LAN-verkeer nie; die besluit moet op die node val, anders val dit glad nie.

Bevestig in watter modus die node werklik is

Mesh-produkte hergebruik drie woorde vir verskillende gedrag, so vertrou die pakketpad meer as die etiket in die app. Brug- of toegangspuntmodus stuur rame deur. Roeteermodus beëindig ’n subnet en hardloop DHCP. Gasmodus plaas kliënte gewoonlik in ’n aparte VLAN met sy eie reëls. ’n Node in roeteermodus agter ’n ander roeteerder is ’n dubbele NAT, en sy kliënte bereik die VPN-roeteerder reeds vertaal, wat beleid op grond van die bronadres verydel.

What you seeWhat it meansNext check
Gateway is the router's LAN address, one MAC for every nodeThe node bridges; the router owns the policyRouter policy for that LAN and VLAN
Gateway is the node's address and DHCP comes from the nodeThe node routes; double NATNode's own VPN client, or a static route plus policy on the router
Gateway is a different subnet on a guest SSIDGuest VLAN, often client-isolatedWhether that VLAN is inside the tunnel policy
Gateway changes when you walk into another roomRoaming across segmentsRepeat the check per node

Om die MAC te bepaal, lees die etiket op die node en vergelyk dit met ip neigh. Vervaardigers druk die basis-MAC en lei die MAC van elke radio af deur een greep te verhoog, so die laaste heksadesimale syfer verskil; vergelyk die voorvoegsel eerder as die hele adres. As die poort se MAC aan die roeteerder se LAN-koppelvlak behoort, roeteer die node nie vir daardie kliënt nie.

Bewys die uitgang op die roeteerder, nie met ’n spoedtoets nie

Die toestand aan die roeteerder se kant is die enigste plek wat die vertaling wys. Lys op OpenWrt die beleidsreëls en roetetabelle en bevestig dan dat die tonnel ’n onlangse handshake het:

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

Op pfSense of OPNsense lê dieselfde bewyse in pfctl -sr vir reëls, pfctl -ss vir lewende toestande en die WireGuard-statusblad vir eweknie-tellers, volgens die WireGuard-kliëntdokumentasie. Filtreer die toestandstabel volgens die kliënt se adres. Wys die toestand die kliënt vertaal na die tonneladres, dan is die verkeer in die tonnel; wys dit die WAN-adres, dan nie, wat die kenteken op die paneel ook al sê.

’n Traceroute vanaf die kliënt voeg een feit by wat die toestandstabel nie kan gee nie: die eerste spring. Is die eerste spring die roeteerder se LAN-adres, het die kliënt die roeteerder regstreeks bereik. Is dit die node se adres met nog ’n private spring daarna, is jy op ’n gerouteerde segment, en daardie tweede spring is die toestel wat die beleid moet hou.

Kyk wat die node buiten ’n adres uitdeel

DHCP-opsies reis saam met die huurkontrak, so ’n node met sy eie DHCP kan ook sy eie DNS en sy eie IPv6-roeteeraankondigings uitdeel. ’n Kliënt kan dus deur die tonnel uitgaan en steeds navrae na ’n oplosser op die node stuur, of ’n globale IPv6-adres kry wat die tonnelbeleid nooit dek nie. Druk albei op die kliënt:

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

Is die oplosser die node en stuur die node na die roeteerder deur, dan volg DNS die tonnel. Los die node plaaslik op of wys dit na die diensverskaffer se oplosser, dan verlaat navrae die tonnel selfs wanneer HTTP dit nie doen nie. IPv6 verdien dieselfde toets: ’n globale adres plus ’n verstekroete wat die tonnel omseil, is ’n lek, en Mesh-firmware laat IPv6 dikwels aan terwyl die VPN-beleid net IPv4 dek.

Breek die tonnel doelbewus en skryf dan die uitslag neer

Haal die tonnel af en kyk na ’n kliënt wat aan daardie node gekoppel is, nie ’n kliënt langs die roeteerder nie. ping en ’n curl met ’n kort tydsperdatum is genoeg; die vraag is of verkeer stop of na die WAN terugval. Stop die tonnel met die roeteerder se eie diensopdrag, byvoorbeeld wg-quick down wg0 of die stop van die OpenVPN-diens, en hou die toets kort.

As die kliënt aanhou werk, faal die node of die roeteerder oop vir daardie segment, en die mesh het die kill switch stilweg ongedaan gemaak. Bring die tonnel terug, bevestig dat die handshake-teller geskuif het, en herhaal die toestandstabelkontrole van die derde stap.

Skryf een ry per node: etiket, SSID, poortadres, MAC-voorvoegsel, uitgang bevestig ja of nee, IPv6 gedek, en gedrag met die tonnel af. Roaming is waar die antwoord verander, so toets die kamers wat jy werklik gebruik. Wanneer een ry nie met die res ooreenstem nie, is daardie node die een om te ondersoek, en die regstelling hoort by die toestel wat daardie ry se poort besit.

Verwante artikels