Cómo comprobar si un satélite Mesh Wi-Fi usa el router VPN

Un satélite que responde al mismo nombre Wi-Fi que el router base no dice casi nada sobre adónde van los paquetes de sus clientes. El nodo es una radio y un puente hasta que se demuestre lo contrario. Lo que decide la salida es la puerta de enlace predeterminada que recibe cada cliente y el modo de reenvío del nodo que tiene delante. Haz estas cinco comprobaciones desde el cliente hacia fuera y tendrás una respuesta defendible, no una impresión sacada de un test de velocidad.

Lee la puerta de enlace que el cliente recibió de verdad

En el cliente, imprime la tabla de rutas y la tabla de vecinos. La ruta predeterminada nombra la dirección que reenvía el tráfico; la entrada de vecino nombra la MAC propietaria de esa dirección. Usa el cliente, no la lista de dispositivos del router, porque una lista de dispositivos muestra asociaciones, no rutas.

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

Windows imprime los mismos datos de otra forma: ipconfig /all da la puerta de enlace predeterminada y arp -a da la MAC. En macOS, route -n get default y arp -an cubren lo mismo.

Compara esa puerta de enlace con dos direcciones que ya conoces: la dirección LAN del router base y la dirección de administración del satélite. Si la puerta de enlace es la dirección LAN del router, el cliente está puenteado al router y la política del router para esa LAN se aplica sin cambios. Si la puerta de enlace es la dirección del satélite, el satélite enruta y el router nunca ve los paquetes del cliente como tráfico LAN; la decisión tiene que tomarse en el nodo o no se toma.

Confirma en qué modo está realmente el nodo

Los productos Mesh reutilizan tres palabras para comportamientos distintos, así que confía en la ruta del paquete antes que en la etiqueta de la aplicación. El modo puente o punto de acceso reenvía tramas. El modo router termina una subred y ejecuta DHCP. El modo invitado suele aparcar a los clientes en un VLAN aparte con sus propias reglas. Un nodo en modo router detrás de otro router es un NAT doble, y sus clientes llegan al router VPN ya traducidos, lo que anula una política basada en la dirección de origen.

Para fijar la MAC, lee la etiqueta del nodo y compárala con ip neigh. Los fabricantes imprimen la MAC base y derivan las MAC de cada radio incrementando un byte, por lo que el último dígito hexadecimal cambia; compara el prefijo en lugar de la dirección completa. Si la MAC de la puerta de enlace pertenece a la interfaz LAN del router, el nodo no enruta para ese cliente.

Demuestra la salida en el router, no con un test de velocidad

El estado del lado del router es el único sitio que muestra la traducción. En OpenWrt, enumera las reglas de política y las tablas de rutas y luego confirma que el túnel tiene un handshake reciente:

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

En pfSense u OPNsense las mismas pruebas están en pfctl -sr para las reglas, pfctl -ss para los estados activos y la página de estado de WireGuard para los contadores de pares, siguiendo la documentación del cliente WireGuard. Filtra la tabla de estados por la dirección del cliente. Si el estado muestra el cliente traducido a la dirección del túnel, el tráfico está dentro del túnel; si muestra la dirección WAN, no lo está, diga lo que diga la insignia del panel.

Un traceroute desde el cliente añade un dato que la tabla de estados no puede dar: el primer salto. Si el primer salto es la dirección LAN del router, el cliente llegó al router directamente. Si es la dirección del nodo seguida de otro salto privado, estás en un segmento enrutado, y ese segundo salto es el dispositivo que debe sostener la política.

Comprueba qué entrega el nodo además de una dirección

Las opciones DHCP viajan con la concesión, así que un nodo que sirve su propio DHCP también puede servir su propio DNS y sus propios anuncios de router IPv6. Un cliente puede por tanto salir por el túnel y aun así enviar consultas a un resolutor del nodo, o recibir una dirección IPv6 global que la política del túnel nunca cubre. Imprime ambas cosas en el cliente:

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

Si el resolutor es el nodo y el nodo reenvía al router, el DNS sigue el túnel. Si el nodo resuelve localmente o apunta al resolutor del ISP, las consultas salen fuera del túnel aunque HTTP no lo haga. IPv6 merece la misma prueba: una dirección global más una ruta predeterminada que evita el túnel es una fuga, y el firmware Mesh a menudo deja IPv6 activo mientras la política VPN solo cubre IPv4.

Rompe el túnel a propósito y anota el resultado

Baja el túnel y observa un cliente asociado a ese nodo, no un cliente junto al router. ping y un curl con tiempo de espera corto bastan; la pregunta es si el tráfico se detiene o vuelve a la WAN. Detén el túnel con el comando de servicio del propio router, por ejemplo wg-quick down wg0 o la parada del servicio OpenVPN, y mantén la prueba corta.

Si el cliente sigue funcionando, el nodo o el router está fallando abierto para ese segmento, y la malla ha deshecho el kill switch sin avisar. Vuelve a levantar el túnel, confirma que el contador de handshake se movió y repite la comprobación de la tabla de estados del tercer paso.

Anota una fila por nodo: etiqueta, SSID, dirección de puerta de enlace, prefijo MAC, salida confirmada sí o no, IPv6 cubierto y comportamiento con el túnel caído. El roaming es donde cambia la respuesta, así que prueba las habitaciones que realmente usas. Cuando una fila no concuerda con las demás, ese nodo es el que hay que investigar, y el arreglo corresponde al dispositivo que posee la puerta de enlace de esa fila.