Como comprobar se un satélite Mesh Wi-Fi usa o router VPN
Segue a pasarela predeterminada, o modo de reenvío do nodo e a táboa de estados do router para demostrar se os clientes dun satélite Mesh pasan pola VPN.
Un satélite que responde ao mesmo nome Wi-Fi que o router base non di case nada sobre onde van os paquetes dos seus clientes. O nodo é unha radio e unha ponte ata que se demostre o contrario. O que decide a saída é a pasarela predeterminada que recibe cada cliente e o modo de reenvío do nodo que ten diante. Fai estas cinco comprobacións desde o cliente cara a fóra e terás unha resposta defendible, non unha impresión sacada dunha proba de velocidade.
Le a pasarela que o cliente recibiu de verdade
No cliente, imprime a táboa de rutas e a táboa de veciños. A ruta predeterminada nomea o enderezo que reenvía o tráfico; a entrada de veciño nomea a MAC que posúe ese enderezo. Usa o cliente, non a lista de dispositivos do router, porque unha lista de dispositivos mostra asociacións, non camiños.
ip route show default
ip -6 route show default
ip neigh showWindows imprime os mesmos datos doutra forma: ipconfig /all dá a pasarela predeterminada e arp -a dá a MAC. En macOS, route -n get default e arp -an cobren o mesmo terreo.
Compara esa pasarela con dous enderezos que xa coñeces: o enderezo LAN do router base e o enderezo de xestión do satélite. Se a pasarela é o enderezo LAN do router, o cliente está en ponte cara ao router e a política do router para esa LAN aplícase sen cambios. Se a pasarela é o enderezo do satélite, o satélite encamiña e o router nunca ve os paquetes do cliente como tráfico LAN; a decisión ten que tomarse no nodo ou non se toma.
Confirma en que modo está realmente o nodo
Os produtos Mesh reutilizan tres palabras para comportamentos distintos, así que confía no camiño do paquete antes que na etiqueta da aplicación. O modo ponte ou punto de acceso reenvía tramas. O modo router remata unha subrede e executa DHCP. O modo convidado adoita aparcar os clientes nunha VLAN aparte con regras propias. Un nodo en modo router detrás doutro router é un NAT dobre, e os seus clientes chegan ao router VPN xa traducidos, o que anula unha política baseada no enderezo de orixe.
| 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 |
Para fixar a MAC, le a etiqueta do nodo e compáraa con ip neigh. Os fabricantes imprimen a MAC base e derivan as MAC de cada radio incrementando un byte, polo que o último díxito hexadecimal cambia; compara o prefixo en vez do enderezo completo. Se a MAC da pasarela pertence á interface LAN do router, o nodo non encamiña para ese cliente.
Demostra a saída no router, non cunha proba de velocidade
O estado do lado do router é o único sitio que mostra a tradución. En OpenWrt, lista as regras de política e as táboas de rutas e despois confirma que o túnel ten un handshake recente:
ip rule show
ip route show table all | grep default
wg showEn pfSense ou OPNsense as mesmas probas están en pfctl -sr para as regras, pfctl -ss para os estados activos e a páxina de estado de WireGuard para os contadores de pares, seguindo a documentación do cliente WireGuard. Filtra a táboa de estados polo enderezo do cliente. Se o estado mostra o cliente traducido ao enderezo do túnel, o tráfico está dentro do túnel; se mostra o enderezo WAN, non o está, diga o que diga a insignia do panel.
Un traceroute desde o cliente engade un dato que a táboa de estados non pode dar: o primeiro salto. Se o primeiro salto é o enderezo LAN do router, o cliente chegou ao router directamente. Se é o enderezo do nodo seguido doutro salto privado, estás nun segmento encamiñado, e ese segundo salto é o dispositivo que debe soster a política.
Comproba que entrega o nodo ademais dun enderezo
As opcións DHCP viaxan coa concesión, así que un nodo que serve o seu propio DHCP tamén pode servir o seu propio DNS e os seus propios anuncios de router IPv6. Un cliente pode, por tanto, saír polo túnel e aínda así enviar consultas a un resolutor do nodo, ou recibir un enderezo IPv6 global que a política do túnel nunca cobre. Imprime as dúas cousas no cliente:
cat /etc/resolv.conf
ip -6 addr show scope globalSe o resolutor é o nodo e o nodo reenvía ao router, o DNS segue o túnel. Se o nodo resolve localmente ou apunta ao resolutor do ISP, as consultas saen fóra do túnel aínda que HTTP non o faga. IPv6 merece a mesma proba: un enderezo global máis unha ruta predeterminada que evita o túnel é unha fuga, e o firmware Mesh adoita deixar IPv6 activo mentres a política VPN só cobre IPv4.
Rompe o túnel a propósito e despois anota o resultado
Baixa o túnel e observa un cliente asociado a ese nodo, non un cliente ao lado do router. ping e un curl con tempo de espera curto abondan; a pregunta é se o tráfico se detén ou volve á WAN. Detén o túnel coa orde de servizo do propio router, por exemplo wg-quick down wg0 ou a parada do servizo OpenVPN, e mantén a proba curta.
Se o cliente segue funcionando, o nodo ou o router está fallando aberto para ese segmento, e a malla desfixo o kill switch en silencio. Volve levantar o túnel, confirma que o contador de handshake se moveu e repite a comprobación da táboa de estados do terceiro paso.
Anota unha fila por nodo: etiqueta, SSID, enderezo de pasarela, prefixo MAC, saída confirmada si ou non, IPv6 cuberto e comportamento co túnel baixado. A itinerancia é onde cambia a resposta, así que proba as habitacións que usas de verdade. Cando unha fila non concorda coas outras, ese nodo é o que hai que investigar, e a corrección corresponde ao dispositivo que posúe a pasarela desa fila.