Come verificare se un satellite Mesh Wi-Fi usa il router VPN

Un satellite che risponde allo stesso nome Wi-Fi del router base non dice quasi nulla su dove finiscono i pacchetti dei suoi client. Il nodo è una radio e un bridge finché non si dimostra il contrario. A decidere l’uscita sono il gateway predefinito che ogni client riceve e la modalità di inoltro del nodo che gli sta davanti. Esegui questi cinque controlli dal client verso l’esterno e avrai una risposta difendibile, non un’impressione ricavata da uno speed test.

Leggi il gateway che il client ha ricevuto davvero

Sul client, stampa la tabella di routing e la tabella dei vicini. La route predefinita indica l’indirizzo che inoltra il traffico; la voce del vicino indica il MAC che possiede quell’indirizzo. Usa il client, non l’elenco dei dispositivi del router, perché un elenco di dispositivi mostra associazioni, non percorsi.

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

Windows stampa gli stessi dati in un’altra forma: ipconfig /all fornisce il gateway predefinito e arp -a fornisce il MAC. Su macOS, route -n get default e arp -an coprono lo stesso terreno.

Confronta quel gateway con due indirizzi che già conosci: l’indirizzo LAN del router base e l’indirizzo di gestione del satellite. Se il gateway è l’indirizzo LAN del router, il client è in bridge verso il router e la politica del router per quella LAN vale senza modifiche. Se il gateway è l’indirizzo del satellite, il satellite fa routing e il router non vede mai i pacchetti del client come traffico LAN; la decisione deve avvenire sul nodo, altrimenti non avviene.

Conferma in quale modalità si trova davvero il nodo

I prodotti Mesh riusano tre parole per comportamenti diversi, quindi fidati del percorso dei pacchetti più che dell’etichetta nell’app. La modalità bridge o access point inoltra i frame. La modalità router termina una sottorete e gestisce il DHCP. La modalità ospite di solito colloca i client su un VLAN separato con regole proprie. Un nodo in modalità router dietro un altro router è un doppio NAT, e i suoi client arrivano al router VPN già tradotti, il che annulla una politica basata sull’indirizzo di origine.

Per fissare il MAC, leggi l’etichetta sul nodo e confrontala con ip neigh. I produttori stampano il MAC di base e ricavano i MAC delle singole radio incrementando un byte, perciò l’ultima cifra esadecimale cambia; confronta il prefisso invece dell’indirizzo intero. Se il MAC del gateway appartiene all’interfaccia LAN del router, il nodo non fa routing per quel client.

Dimostra l’uscita sul router, non con uno speed test

Lo stato lato router è l’unico posto che mostra la traduzione. Su OpenWrt, elenca le regole di policy e le tabelle di routing, poi conferma che il tunnel ha un handshake recente:

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

Su pfSense o OPNsense le stesse prove stanno in pfctl -sr per le regole, pfctl -ss per gli stati attivi e nella pagina di stato di WireGuard per i contatori dei peer, seguendo la documentazione del client WireGuard. Filtra la tabella degli stati per l’indirizzo del client. Se lo stato mostra il client tradotto verso l’indirizzo del tunnel, il traffico è nel tunnel; se mostra l’indirizzo WAN, non lo è, qualunque cosa dica il badge della dashboard.

Un traceroute dal client aggiunge un dato che la tabella degli stati non può dare: il primo hop. Se il primo hop è l’indirizzo LAN del router, il client ha raggiunto il router direttamente. Se è l’indirizzo del nodo seguito da un altro hop privato, sei su un segmento instradato, e quel secondo hop è il dispositivo che deve detenere la politica.

Controlla che cosa distribuisce il nodo oltre a un indirizzo

Le opzioni DHCP viaggiano con il lease, quindi un nodo che serve il proprio DHCP può servire anche il proprio DNS e i propri annunci di router IPv6. Un client può quindi uscire dal tunnel e continuare a inviare query a un resolver sul nodo, oppure ottenere un indirizzo IPv6 globale che la politica del tunnel non copre mai. Stampa entrambe le cose sul client:

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

Se il resolver è il nodo e il nodo inoltra al router, il DNS segue il tunnel. Se il nodo risolve in locale o punta al resolver dell’ISP, le query escono fuori dal tunnel anche quando HTTP non lo fa. IPv6 merita la stessa prova: un indirizzo globale più una route predefinita che aggira il tunnel è una fuga, e il firmware Mesh spesso lascia IPv6 attivo mentre la politica VPN copre solo IPv4.

Interrompi il tunnel di proposito, poi annota il risultato

Abbatti il tunnel e osserva un client associato a quel nodo, non un client accanto al router. ping e un curl con timeout breve bastano; la domanda è se il traffico si ferma o ricade sulla WAN. Ferma il tunnel con il comando di servizio del router stesso, per esempio wg-quick down wg0 oppure l’arresto del servizio OpenVPN, e tieni la prova breve.

Se il client continua a funzionare, il nodo o il router stanno fallendo in aperto per quel segmento, e la mesh ha annullato in silenzio il kill switch. Riporta su il tunnel, conferma che il contatore dell’handshake si è mosso e ripeti il controllo della tabella degli stati del terzo passo.

Annota una riga per nodo: etichetta, SSID, indirizzo del gateway, prefisso MAC, uscita confermata sì o no, IPv6 coperto e comportamento a tunnel abbassato. Il roaming è il punto in cui la risposta cambia, quindi prova le stanze che usi davvero. Quando una riga non concorda con le altre, quel nodo è quello da indagare, e la correzione spetta al dispositivo che possiede il gateway di quella riga.