Hoe kontrolearje jo oft in Mesh Wi-Fi-satelliet de VPN-router brûkt
Folch de standertgateway, de trochstjoermodus fan de node en de steattabel fan de router om te bewizen oft de kliïnten fan in Mesh-satelliet troch de VPN geane.
In satelliet dy’t op deselde Wi-Fi-namme as de basisrouter antwurdet, seit hast neat oer wêr’t de pakketten fan syn kliïnten hinne geane. De node is in radio en in brêge oant it tsjinoerstelde bewiisd is. Wat de útgong beslút, is de standertgateway dy’t elke kliïnt krijt en de trochstjoermodus fan de node dêrfoar. Doch dizze fiif kontrôles fan de kliïnt nei bûten, en do hast in antwurd datsto ferdigenje kinst, net in yndruk út in snelheidstest.
Lês de gateway dy’t de kliïnt echt krigen hat
Print op de kliïnt de rûtetabel en de buertabel. De standertrûte neamt it adres dat ferkear trochstjoert; de buerynstjoer neamt de MAC dy’t dat adres besit. Brûk de kliïnt, net de apparatielist fan de router, want in apparatielist lit assosjaasjes sjen, net paden.
ip route show default
ip -6 route show default
ip neigh showWindows print deselde feiten yn in oare foarm: ipconfig /all jout de standertgateway en arp -a jout de MAC. Op macOS dekke route -n get default en arp -an deselde grûn.
Fergelykje dy gateway mei twa adressen dy’tsto al kinst: it LAN-adres fan de basisrouter en it behearderes fan de satelliet. Is de gateway it LAN-adres fan de router, dan is de kliïnt fia in brêge oan de router keppele en jildt it belied fan de router foar dat netwurk ûnferoare. Is de gateway it adres fan de satelliet, dan rûtet de satelliet, en de router sjocht de pakketten fan de kliïnt nea as LAN-ferkear; it beslút moat op de node falle, oars falt it hielendal net.
Befêstigje yn hokker modus de node echt is
Mesh-produkten brûke trije wurden opnij foar ferskillend gedrach, fertrou dêrom it pakketpaad mear as it label yn de app. Brêge- of tagongspuntmodus stjoert frames troch. Rûtermodus einiget in subnet en draait DHCP. Gastmodus set kliïnten meastentiids yn in apart VLAN mei eigen regels. In node yn rûtermodus efter in oare router is in dûbele NAT, en syn kliïnten berikke de VPN-router al fertaald, wat belied op grûn fan it boarne-adres ûnderminet.
| 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 |
Om de MAC fêst te stellen, lês it label op de node en fergelykje it mei ip neigh. Fabrikanten printsje de basis-MAC en liede de MAC fan elke radio ôf troch ien byte te ferheegjen, sadat it lêste heksadesimale sifer ferskilt; fergelykje it foarheaksel ynstee fan it hiele adres. Heart de MAC fan de gateway by it LAN-ynterface fan de router, dan rûtet de node net foar dy kliïnt.
Bewiis de útgong op de router, net mei in snelheidstest
De steat oan de routerkant is it iennige plak dat de fertaling lit sjen. List op OpenWrt de beliedsregels en rûtetabellen op en befêstigje dan dat de tunnel in resinte handshake hat:
ip rule show
ip route show table all | grep default
wg showOp pfSense of OPNsense lizze deselde bewiizen yn pfctl -sr foar regels, pfctl -ss foar libbene steaten en de WireGuard-steatspagina foar pear-tellers, neffens de WireGuard-kliïntdokumintaasje. Filterje de steattabel op it adres fan de kliïnt. Lit de steat de kliïnt fertaald nei it tunneladres sjen, dan is it ferkear yn de tunnel; lit it it WAN-adres sjen, dan net, wat it badge op it paniel ek seit.
In traceroute fan de kliïnt foeget ien feit ta dat de steattabel net jaan kin: de earste sprong. Is de earste sprong it LAN-adres fan de router, dan hat de kliïnt de router direkt berikt. Is it it adres fan de node mei noch in priveesprong dêrnei, dan bist op in rûtearre segmint, en dy twadde sprong is it apparaat dat it belied hâlde moat.
Besjoch wat de node njonken in adres útdielt
DHCP-opsjes reizgje mei it hierkontrakt, sadat in node mei eigen DHCP ek eigen DNS en eigen IPv6-routeroankundigings útdiele kin. In kliïnt kin dêrom troch de tunnel nei bûten gean en dochs fragen nei in oplosser op de node stjoere, of in globale IPv6-adres krije dat it tunnelbelied nea dekt. Print beide op de kliïnt:
cat /etc/resolv.conf
ip -6 addr show scope globalIs de oplosser de node en stjoert de node nei de router troch, dan folget DNS de tunnel. Lost de node lokaal op of wiist er nei de oplosser fan de provider, dan ferlitte de fragen de tunnel sels as HTTP dat net docht. IPv6 fertsjinnet deselde test: in globale adres plus in standertrûte dy’t de tunnel omgiet is in lek, en Mesh-firmware lit IPv6 faak oan wylst it VPN-belied allinne IPv4 dekt.
Breek de tunnel mei opsetsin en skriuw dan de útslach op
Helje de tunnel del en sjoch nei in kliïnt dy’t oan dy node keppele is, net in kliïnt njonken de router. ping en in curl mei in koarte tiidlimit is genôch; de fraach is oft ferkear stoppt of weromfalt nei de WAN. Stop de tunnel mei it eigen tsjinstkommando fan de router, bygelyks wg-quick down wg0 of it stopjen fan de OpenVPN-tsjinst, en hâld de test koart.
As de kliïnt trochwurket, falt de node of de router iepen foar dat segmint, en it mesh hat de kill switch stil útskeakele. Bring de tunnel werom, befêstigje dat de handshake-teller skood is, en werhelje de steattabelkontrôle fan de tredde stap.
Skriuw ien rigel per node: label, SSID, gatewayadres, MAC-foarheaksel, útgong befêstige ja of nee, IPv6 dekt, en gedrach mei de tunnel del. Roaming is wêr’t it antwurd feroaret, test dêrom de keamers dy’tsto echt brûkst. As ien rigel net mei de rest oerienkomt, is dy node dejinge om te ûndersykjen, en de reparaasje heart by it apparaat dat it gateway fan dy rigel besit.