Isolamento dei client Wi-Fi contro accesso locale via VPN: cosa vi blocca

Mettete due telefoni sullo stesso SSID ospiti e nessuno vede l’altro, eppure entrambi raggiungono internet. Aggiungete un client VPN su uno dei due e la stampante a tre metri resta invisibile, mentre un server su un altro continente risponde ai ping. Nel tunnel non c’è nulla di rotto; entrano in gioco due decisioni di accesso separate e solo una riguarda l’instradamento. Il punto di accesso decide se i client wireless possono parlarsi, e il client VPN decide quali destinazioni escono dal tunnel. Confondere le due cose produce ore di modifiche di configurazione inutili.

Le due porte sono indipendenti

L’isolamento dei client è una decisione di commutazione. Il punto di accesso accetta un frame da una stazione associata, guarda la destinazione, nota che la destinazione è un’altra stazione sullo stesso bridge e lo scarta. L’indirizzo IP della stazione è irrilevante per quella decisione, e il VPN altrettanto.

L’instradamento è un’altra decisione, presa sul client. La tabella di routing del VPN decide se un pacchetto per 192.168.1.50 entra nel tunnel o esce dall’interfaccia Wi-Fi. Se il pacchetto esce dal Wi-Fi e il punto di accesso isola i client, muore al punto di accesso. Se il pacchetto entra nel tunnel, il punto di accesso non vede mai la destinazione originale e non può isolare nulla.

Cosa blocca l’isolamento su un punto di accesso tipico

I produttori lo distribuiscono con nomi diversi: isolamento dei client, isolamento AP, isolamento delle stazioni o una rete ospiti che lo implica. In OpenWrt l’opzione per interfaccia è isolate nella configurazione wireless, come descritto nella documentazione wireless, e un SSID ospiti di solito riceve il proprio bridge e la propria zona firewall. L’effetto è che i frame unicast tra client non vengono bridgati, quindi un ping, una connessione SMB o un lavoro di stampa verso un vicino fallisce anche se entrambi i dispositivi mostrano segnale pieno.

I protocolli di scoperta soffrono per primi e nel modo più visibile. mDNS per stampanti e dispositivi multimediali viaggia in multicast verso 224.0.0.251, SSDP usa 239.255.255.250, e se quei frame attraversano il bridge dipende dal produttore e dal fatto che la conversione da multicast a unicast sia attiva. Un dispositivo che manca da un elenco è una prova più debole di una connessione diretta fallita verso un indirizzo noto.

Cosa cambia il VPN e cosa non può cambiare

Un tunnel completo prende la rotta predefinita, quindi le sottoreti locali si raggiungono solo se il client mantiene per esse una rotta più specifica. I tunnel divisi fanno il contrario e preservano l’accesso locale per progetto. Nessuna delle due impostazioni può costringere un punto di accesso isolante a inoltrare un frame tra due dei suoi client, per questo consentire il traffico locale nel client VPN è necessario ma non sufficiente.

Il caso inverso è altrettanto comune. Il punto di accesso consente il traffico tra pari, il client VPN esclude la sottorete locale dal tunnel, e la stampante continua a non rispondere perché il firewall dell’host tratta la rete Wi-Fi come pubblica. Tre livelli, tre valori predefiniti diversi, e solo la rotta è visibile nella maggior parte dei log VPN.

Scoprite quale porta è chiusa

Iniziate con un test che toglie il VPN dallo scenario: collegate due dispositivi comuni allo stesso SSID e provate a raggiungere l’uno dall’altro per indirizzo. Se fallisce, il punto di accesso isola e nessuna impostazione VPN lo sistemerà. Se riesce, passate al client ed eseguite ip route get 192.168.1.50 su Linux o Find-NetRoute -RemoteIPAddress 192.168.1.50 su Windows; l’output nomina l’interfaccia che il pacchetto userà.

Quando la rotta punta all’interfaccia Wi-Fi, il pacchetto esce in chiaro e la domanda diventa se il punto di accesso e il firewall dell’host lo permettano. Quando la rotta punta al tunnel, la destinazione viene inviata al server VPN, cosa sbagliata per un dispositivo sulla stessa LAN e che di solito significa che l’elenco consentito del tunnel è troppo ampio.

Una connessione diretta alla porta della stampante è un test migliore di un elenco di scoperta. nc -vz 192.168.1.50 9100 su Linux o Test-NetConnection 192.168.1.50 -Port 9100 in PowerShell vi dice se l’indirizzo è raggiungibile, prima che qualsiasi accoppiamento a livello applicativo entri nella discussione.

Scegliete la correzione per la rete in cui siete

Su una rete di hotel o ospiti l’isolamento è deliberato e non dovreste cercare di aggirarlo. Trattate il dispositivo locale come irraggiungibile, usate il VPN per raggiungere un host che possa stampare o condividere, e smettete di trattare l’SSID come una LAN.

A casa, disattivare l’isolamento sullo SSID principale è ragionevole quando i dispositivi sono vostri, mentre lo SSID ospiti resta isolato. L’impostazione vive nella configurazione wireless del punto di accesso e appartiene lì, non alle eccezioni del firewall su ogni client.

In ufficio, date per scontato che il punto di accesso, la VLAN e il firewall dell’host siano tutti intenzionali. Escalate con i risultati dei test invece di chiedere di disattivare l’isolamento, perché una rete che separa i client di solito protegge qualcosa.

Verificate l’applicazione, non solo il ping

Un ping riuscito dimostra il percorso, non il servizio. Le stampanti spesso accettano 9100 grezzo o IPP sulla 631 ma rifiutano la scoperta, e una condivisione file richiede 445 più una risoluzione dei nomi funzionante. Confermate la porta usata dall’applicazione, poi riprovate l’attività reale sul dispositivo.

Tenete i due livelli separati nelle vostre note: cosa permette la rete Wi-Fi e cosa instrada il VPN. La prossima volta che un dispositivo scompare da un elenco, quella separazione vi dirà dove guardare per primo.