La modalità SOCKS di NetGuard copre TCP, non ogni protocollo

NetGuard occupa l'interfaccia VPN di Android per filtrare il traffico e può consegnare le connessioni supportate a un endpoint SOCKS. Questi due fatti vengono spesso letti come «il telefono è su una VPN», una conclusione che il meccanismo non supporta. Il filtro vede i pacchetti; il proxy vede solo le connessioni che gli sono state effettivamente consegnate. Tra queste due affermazioni sta tutta la questione della copertura.

Le FAQ del progetto originale documentano sia la limitazione a un solo servizio sia l'opzione SOCKS. L'esistenza dell'opzione non è prova che ogni pacchetto consentito la usi, e proprio da questo divario nascono le domande sulla copertura.

Due percorsi di inoltro dentro una sola app

Il lato TCP dell'implementazione contiene la gestione delle connessioni SOCKS, quindi una connessione TCP consentita può essere negoziata con il proxy e trasportata attraverso di esso. Il lato UDP ha un percorso socket separato, e la sua gestione di invio e ricezione non dipende da quella negoziazione TCP. Un datagramma che il filtro consente può quindi raggiungere la rete ordinaria senza mai passare dal proxy. Nulla di tutto ciò è un difetto dell'app; è semplicemente ciò che i due percorsi implementano.

Questa distinzione ha una conseguenza che le persone descrivono male in entrambe le direzioni. Chiamare ogni pacchetto UDP una fuga ignora le regole di blocco, perché un datagramma negato non esce mai. Chiamare VPN l'intera disposizione ignora il percorso diretto consentito, perché parte del traffico esce davvero senza proxy. Quello che hai è un dispositivo filtrato con proxy parziale, e la descrizione onesta è una matrice, non un'etichetta.

Annunciare UDP non significa implementarlo

Un server SOCKS che dichiara il supporto UDP non aggiunge la corrispondente gestione lato client all'app sul tuo telefono. Le caratteristiche teoriche del protocollo e il comportamento della build installata sono argomenti diversi, e solo il secondo descrive il tuo traffico.

Controlla la versione e la configurazione che esegui davvero, poi prova un flusso di datagrammi innocuo e osserva se appare al proxy. Qualunque altra cosa è un'inferenza da un elenco di funzionalità, e gli elenchi di funzionalità descrivono intenzioni, non percorsi di codice.

DNS è un terzo percorso, non un dettaglio

La risoluzione dei nomi aggiunge il proprio ramo alla matrice. Un forwarder DNS locale, una normale query UDP, un nome host di destinazione risolto dal proxy stesso e un resolver cifrato nel browser sono quattro disposizioni distinte. Differiscono per chi vede la query e per quale percorso di rete la trasporta, e mescolarle produce un test che non dimostra nulla sulle altre.

Decidi deliberatamente quale vuoi. Se il requisito è che i nomi si risolvano attraverso il tunnel, una semplice impostazione del browser non lo fornirà, e un proxy che risolve da sé i nomi host cambia la risposta solo per le connessioni che gestisce davvero.

Il trasporto tramite proxy non è privato automaticamente

SOCKS semplice non è un collegamento cifrato tra telefono e proxy. Se l'endpoint viene raggiunto tramite un altro percorso protetto, nomina quel percorso e la sua politica di errore, perché un ripiego sulla rete aperta trasforma una disposizione privata in pubblica senza avviso. Anche l'autenticazione del proxy conta: un ascoltatore aperto su un dispositivo condiviso è un servizio di cui nessuno risponde.

Le disposizioni tra profili meritano lo stesso esame. Una VPN del profilo di lavoro protegge solo il traffico che usa il suo percorso, e la coesistenza di un firewall del profilo personale con un tunnel di lavoro non prova che la connessione successiva del firewall raggiunga quel tunnel. Verifica la raggiungibilità e l'autenticazione invece di presumere che i due profili collaborino.

Verifica la copertura con una matrice, non con un caricamento di pagina

Per una valutazione autorizzata, scegli esempi innocui che rappresentino ogni classe che ti interessa: TCP richiesto, UDP consentito e DNS in entrambe le famiglie di indirizzi. Per ciascuno, registra se è stato proxato, bloccato o inviato direttamente. Quella singola tabella è il risultato, ed è molto più utile di uno screenshot di una pagina caricata.

Se il requisito è che tutto il traffico applicativo selezionato attraversi un tunnel remoto, scegli un'implementazione con filtraggio e tunneling combinati esplicitamente supportati. Una composizione con solo proxy TCP resta utile per compiti più ristretti, purché l'altro traffico sia gestito di proposito e non dimenticato.