Marcatore VPN sul dispositivo o indirizzo di uscita: quale dimostra cosa?

L’app del telefono e il server remoto partono da fatti diversi, e nessuno dei due può prendere in prestito quelli dell’altro. L’app può interrogare il sistema operativo sulla rete che usa, mentre il server sa solo ciò che arriva sulla connessione. Eseguire il proprio endpoint riscrive il secondo e lascia intatto il primo. Quale dei due risponde alla vostra domanda dipende dalla domanda stessa.

Due punti di osservazione, due tipi di prova

La prova locale descrive il dispositivo. Comprende l’interfaccia che trasporta il traffico, il trasporto che la piattaforma riporta e ciò che l’app chiamante può interrogare. La prova remota descrive la connessione: indirizzo di origine, protocollo, tempi e tutto ciò che l’app sceglie di inviare. Nessun punto di osservazione è un sovrainsieme dell’altro.

Mescolare i due produce affermazioni che suonano precise e non possono essere verificate. Un marcatore dimostra qualcosa su un oggetto di rete del dispositivo, non su come un servizio remoto classifica la richiesta.

Prima di discutere di rilevamento, annotate a quale punto si riferisce la domanda. Si tratta di sapere se un’app particolare può capire che un tunnel è attivo, o se un servizio può dedurre da dove è arrivata la richiesta? Sono indagini separate, e la risposta a una non dice nulla sull’altra.

Che cosa può riportare un’interfaccia locale della piattaforma

Android offre un marcatore specifico. L’oggetto NetworkCapabilities può riportare TRANSPORT_VPN, e hasTransport verifica se quel trasporto è presente sull’oggetto. L’app ottiene l’oggetto dal servizio di connettività e lo legge, soggetto al permesso sullo stato della rete.

Il risultato è informazione locale della piattaforma, non una ricerca negli intervalli di indirizzi di un fornitore. Descrive la rete che l’app chiamante sta usando.

Due limiti contano. Una regola di tunnel diviso che esclude un’app può dare sullo stesso telefono una risposta diversa da quella che vede un collega, perché l’app può essere vincolata altrove. Il marcatore esiste anche perché il sistema operativo modella interfacce VPN, non perché un’app particolare lo raccolga. Se un’app legge il campo, lo inoltra o lo ignora è una proprietà di quell’app. Il suo manifest e la sua documentazione sono le uniche fonti affidabili per quella domanda.

adb shell dumpsys connectivity | grep -i -m5 vpn

Che cosa può vedere un servizio remoto

Un server vede l’indirizzo di origine della connessione, il trasporto e i tempi, e può arricchire l’indirizzo con dati di registro o di instradamento. Può anche ricevere tutto ciò che l’app invia, compresa la posizione quando l’app la richiede e l’utente acconsente. Quei canali sono separati, e solo uno assomiglia a una ricerca di indirizzo.

Un indirizzo registrato a un fornitore di hosting suggerisce un tunnel, mentre uno registrato su una rete residenziale suggerisce una connessione domestica. Entrambi sono indizi statistici, non fatti sul dispositivo.

Un indirizzo residenziale non colloca la persona a quell’indirizzo, e un indirizzo di hosting non nomina l’operatore né il paese. Un servizio che tratta l’inferenza come certezza a volte sbaglierà senza poterlo rilevare. Se il requisito è l’affidabilità e non un’euristica, i dati dell’indirizzo non possono fornirla, e un progetto che lo dice è più onesto di uno che nasconde la congettura.

Perché un’uscita auto-ospitata cambia solo un lato

Eseguire il proprio endpoint cambia l’indirizzo di origine che un servizio remoto osserva, il che può spostarlo fuori dagli intervalli che quel servizio associa ai fornitori commerciali. Non cambia nulla nel modello di rete locale, perché il tunnel resta un tunnel e il sistema operativo continua a riportarlo.

Un lato della prova si muove; l’altro resta fermo. Lo scarto tra i due è il punto in cui le aspettative si rompono.

Un browser è un terzo caso con interfacce e restrizioni proprie. Il contenuto web non può leggere un oggetto nativo delle capacità, e trattare una funzione del sistema operativo mobile come disponibile a una pagina web è un errore di categoria. Se la domanda riguarda un sito web, studiate ciò che un sito può davvero ottenere invece di traslitterare un’API di piattaforma.

Decidete con la domanda che fate

Se la domanda è se un’app particolare può osservare lo stato del tunnel, l’interfaccia di piattaforma è il posto giusto da guardare, e la risposta vive nel codice e nei permessi di quell’app. Se la domanda è cosa un servizio può dedurre, i metadati della connessione sono la prova. Una questione legale o contrattuale non è risolta da nessuno dei due.

Nominate la domanda in una frase prima di raccogliere qualsiasi cosa. Quella frase decide quale punto di osservazione conta e impedisce che l’indagine scivoli in un’altra discussione.

Etichettate ogni osservazione secondo la sua fonte quando la riportate, perché un’affermazione senza etichetta non può essere riesaminata. Un marcatore locale e un’inferenza sull’indirizzo sono entrambi utili e nessuno è conclusivo, ed è per questo che fonderli in un solo verdetto è un errore.

Quando un servizio rifiuta una connessione autorizzata, usate la sua via di revisione supportata invece di cambiare un’impostazione locale per nascondere un segnale. Rimuovere un’osservazione non dimostra mai che le altre siano sparite.