Il Wi-Fi passa dal VPN del router. E le porte cablate?

Il portatile in Wi-Fi mostra l’indirizzo di uscita del VPN, e il desktop cablato nella stanza accanto mostra quello del provider. Entrambi sono collegati allo stesso router, quindi la differenza non è nella configurazione del VPN. Sta in quale interfaccia, VLAN o politica ha attraversato davvero il traffico. La copertura è una proprietà di ogni percorso, non una proprietà della scatola.

Confrontare i due client fianco a fianco trova la differenza più in fretta che leggere le regole del router.

Due percorsi verso lo stesso router

Un router con client VPN può instradare il traffico da un bridge, una VLAN o un elenco di porte e lasciare il resto sul WAN. È un progetto normale, ed è per questo che un test senza fili riuscito dimostra solo il percorso senza fili. Uno switch gestito può anche mettere una porta a muro su un segmento diverso da quello usato dall’access point, senza che nessuno tocchi il router. Le politiche basate sulle porte sono le più facili da mancare, perché la porta sembra parte della stessa LAN.

Stesso hardware, politica diversa. La scatola fisica non è il confine che credete.

Confrontate il gateway che ogni client usa davvero

Sul dispositivo cablato leggete l’interfaccia attiva, il suo indirizzo e il suo gateway predefinito. Su una macchina con Wi-Fi ed Ethernet entrambi attivi, la metrica di instradamento decide chi vince, e spesso non è quella che vi aspettate. Confrontate quel gateway con quello usato dal client senza fili, e controllate a quale rete del router appartiene la porta dello switch. La ricetta del client WireGuard di pfSense mostra come un solo router possa possedere un tunnel lasciando in pace le altre interfacce.

Se i due gateway differiscono, avete la risposta prima di toccare una sola regola del firewall.

Confrontate DNS e IPv6 separatamente

Un client cablato con resolver configurato a mano può aggirare del tutto la politica DNS del router, anche quando il suo traffico è instradato correttamente. IPv6 è l’altra metà: un tunnel che gestisce solo IPv4 può lasciare il traffico IPv6 sul percorso nativo. Provate una risoluzione di nome e una destinazione IPv6 dal dispositivo cablato, non solo un controllo dell’indirizzo IPv4. Usate una query a cui solo il resolver del router potrebbe rispondere, come un nome host interno.

Ognuno di questi è un confronto separato, e ognuno può fallire da solo.

Confrontate cosa succede quando il tunnel cade

Se il progetto richiede accesso solo tramite VPN, fermate il tunnel e provate il client cablato con traffico innocuo. Un dispositivo cablato che ricade sul WAN normale resta in linea ma manca il percorso previsto, cosa che a chi controlla solo la connettività sembra un successo. Il client senza fili può comportarsi diversamente, e quella differenza è il confronto che vale la pena.

Il comportamento in caso di guasto fa parte della copertura, non è un caso limite successivo.

Attribuite il risultato al livello giusto

Un client VPN a livello di dispositivo o un proxy del browser sulla macchina cablata possono cambiare l’indirizzo di uscita misurato indipendentemente dal router. Annotate quali livelli erano attivi durante il test, altrimenti un cambio di indirizzo riuscito viene attribuito al gateway sbagliato. La stessa cautela vale per un risultato in cache precedente alla modifica.

Provate traffico nuovo, annotate i livelli e scrivete il segmento e l’interfaccia. È quella registrazione che rende il confronto successivo significativo invece di un’altra supposizione.