Com comprovar si un satèl·lit Mesh Wi-Fi fa servir el router VPN

Un satèl·lit que respon al mateix nom Wi-Fi que el router base no diu gairebé res sobre on van els paquets dels seus clients. El node és una ràdio i un pont fins que no es demostri el contrari. El que decideix la sortida és la passarel·la predeterminada que rep cada client i el mode de reenviament del node que té al davant. Fes aquestes cinc comprovacions des del client cap enfora i tindràs una resposta defensable, no una impressió treta d’una prova de velocitat.

Llegeix la passarel·la que el client ha rebut de debò

Al client, imprimeix la taula de rutes i la taula de veïns. La ruta predeterminada anomena l’adreça que reenvia el trànsit; l’entrada de veí anomena la MAC que posseeix aquesta adreça. Fes servir el client, no la llista de dispositius del router, perquè una llista de dispositius mostra associacions, no camins.

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

Windows imprimeix els mateixos fets d’una altra manera: ipconfig /all dona la passarel·la predeterminada i arp -a dona la MAC. A macOS, route -n get default i arp -an cobreixen el mateix terreny.

Compara aquesta passarel·la amb dues adreces que ja coneixes: l’adreça LAN del router base i l’adreça de gestió del satèl·lit. Si la passarel·la és l’adreça LAN del router, el client està pontat al router i la política del router per a aquesta LAN s’aplica sense canvis. Si la passarel·la és l’adreça del satèl·lit, el satèl·lit encamina i el router no veu mai els paquets del client com a trànsit LAN; la decisió s’ha de prendre al node o no es pren.

Confirma en quin mode és realment el node

Els productes Mesh reutilitzen tres paraules per a comportaments diferents, així que confia en el camí del paquet abans que en l’etiqueta de l’aplicació. El mode pont o punt d’accés reenvia trames. El mode router acaba una subxarxa i executa DHCP. El mode convidat sol aparcar els clients en una VLAN a part amb regles pròpies. Un node en mode router darrere d’un altre router és un NAT doble, i els seus clients arriben al router VPN ja traduïts, cosa que anul·la una política basada en l’adreça d’origen.

Per fixar la MAC, llegeix l’etiqueta del node i compara-la amb ip neigh. Els fabricants imprimeixen la MAC base i deriven les MAC de cada ràdio incrementant un byte, per tant l’últim dígit hexadecimal canvia; compara el prefix en lloc de l’adreça sencera. Si la MAC de la passarel·la pertany a la interfície LAN del router, el node no encamina per a aquest client.

Demostra la sortida al router, no amb una prova de velocitat

L’estat del costat del router és l’únic lloc que mostra la traducció. A OpenWrt, llista les regles de política i les taules d’encaminament i després confirma que el túnel té un handshake recent:

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

A pfSense o OPNsense les mateixes proves són a pfctl -sr per a les regles, pfctl -ss per als estats actius i la pàgina d’estat de WireGuard per als comptadors de parells, seguint la documentació del client WireGuard. Filtra la taula d’estats per l’adreça del client. Si l’estat mostra el client traduït a l’adreça del túnel, el trànsit és dins del túnel; si mostra l’adreça WAN, no ho és, digui el que digui la insígnia del tauler.

Un traceroute des del client afegeix un fet que la taula d’estats no pot donar: el primer salt. Si el primer salt és l’adreça LAN del router, el client ha arribat al router directament. Si és l’adreça del node seguida d’un altre salt privat, ets en un segment encaminat, i aquest segon salt és el dispositiu que ha de sostenir la política.

Comprova què entrega el node a més d’una adreça

Les opcions DHCP viatgen amb la concessió, així que un node que serveix el seu propi DHCP també pot servir el seu propi DNS i els seus propis anuncis de router IPv6. Un client pot, per tant, sortir pel túnel i tot i així enviar consultes a un resolutor del node, o rebre una adreça IPv6 global que la política del túnel no cobreix mai. Imprimeix les dues coses al client:

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

Si el resolutor és el node i el node reenvia al router, el DNS segueix el túnel. Si el node resol localment o apunta al resolutor de l’ISP, les consultes surten fora del túnel encara que HTTP no ho faci. IPv6 mereix la mateixa prova: una adreça global més una ruta predeterminada que evita el túnel és una fuita, i el firmware Mesh sovint deixa IPv6 actiu mentre la política VPN només cobreix IPv4.

Trenca el túnel a propòsit i després anota el resultat

Baixa el túnel i observa un client associat a aquest node, no un client al costat del router. ping i un curl amb temps d’espera curt són prou; la pregunta és si el trànsit s’atura o torna a la WAN. Atura el túnel amb l’ordre de servei del mateix router, per exemple wg-quick down wg0 o l’aturada del servei OpenVPN, i mantén la prova curta.

Si el client continua funcionant, el node o el router està fallant obert per a aquest segment, i la malla ha desfet el kill switch en silenci. Torna a aixecar el túnel, confirma que el comptador de handshake s’ha mogut i repeteix la comprovació de la taula d’estats del tercer pas.

Anota una fila per node: etiqueta, SSID, adreça de passarel·la, prefix MAC, sortida confirmada sí o no, IPv6 cobert i comportament amb el túnel baixat. L’itinerància és on canvia la resposta, així que prova les habitacions que fas servir de debò. Quan una fila no concorda amb les altres, aquest node és el que cal investigar, i l’arranjament correspon al dispositiu que posseeix la passarel·la d’aquella fila.