Perché il traffico del debug wireless non è prova di una fuga VPN

Avete attivato il debug wireless, collegato un portatile e la sessione ha continuato a funzionare mentre la VPN era attiva. Sembra che qualcosa sia sgusciato oltre il tunnel. Quasi certamente no. Una sessione di debug e la richiesta di un'app a un sito web sono relazioni di rete diverse, e solo una delle due dovrebbe attraversare il tunnel.

Ho incontrato questa lettura sbagliata due volte: una con il telefono e il portatile sulla stessa Wi-Fi, e una dopo un riavvio, quando l'accoppiamento era sopravvissuto. In entrambi i casi la VPN faceva esattamente ciò per cui era configurata.

Nominate l'osservazione prima di nominare il bug

Tre eventi possono precedere un'affermazione di fuga, e non sono intercambiabili. Uno strumento può scoprire un servizio, il dispositivo può approvare una workstation o una sessione autorizzata può davvero trasportare comandi e byte. Annotate quale avete visto, perché ciascuno dimostra meno di quanto si supponga.

La scoperta è di solito mDNS o una scansione delle porte. L'accoppiamento è una decisione di registrazione presa sul telefono, confermata con un codice digitato dall'utente. Una sessione attiva significa che il traffico si è spostato tra due endpoint accoppiati. Nulla di ciò descrive dove va la richiesta HTTPS di un'app.

Tenete destinazione, interfaccia, famiglia di indirizzi, timestamp e profilo utente collegati all'evento. Senza questi dettagli l'osservazione non può essere confrontata con la politica di rete locale prevista, né con la build VPN in esecuzione in quel momento.

Perché i due percorsi non si incontrano mai

Il debug wireless è una connessione in ingresso verso il dispositivo. adbd ascolta su una porta legata all'interfaccia Wi-Fi, e la workstation vi si connette dopo l'accoppiamento. La direzione conta: il vostro portatile arriva dentro il telefono, non il contrario. È l'opposto di una fuga in uscita.

Il traffico internet di un'app esce dall'interfaccia tunnel installata da VpnService, abbinata per UID e regole di routing. adbd è un demone di sistema eseguito come utente shell, non un'app dentro quell'insieme di routing. Resta sul collegamento Wi-Fi sottostante anche quando ogni app è vincolata al tunnel.

La modalità di blocco impone il tunnel alle app coperte. Non trasforma un socket in ascolto in un percorso di uscita.

Per questo una sessione ADB funzionante e un kill switch funzionante coesistono senza contraddizione. Per dimostrare una fuga bisogna osservare la direzione che dovrebbe essere bloccata.

Che aspetto ha davvero un test di uscita

Testate l'app coperta, non il canale di debug. Create deliberatamente la condizione di errore, poi fate una nuova richiesta e registrate cosa è successo.

1. Confermate che la VPN è l'unico percorso: attivate la VPN sempre attiva con il blocco delle connessioni senza VPN.
2. Fermate la VPN nel modo supportato e confermate che l'app segnala assenza di connettività.
3. Inviate una richiesta innocua da quell'app e annotate se fallisce o riesce.
4. Ripetete con il debug wireless attivo e poi disattivo, così da isolare la variabile.

Una richiesta bloccata in quelle condizioni è una prova. Una sessione ADB riuscita non lo è, e nemmeno un singolo ping da un'app terminale.

Se la richiesta riesce davvero mentre il blocco è attivo, registrate l'UID dell'app e la sua autorizzazione VPN, la rete attiva e la versione del client. Quella combinazione è un vero riscontro.

L'accoppiamento sopravvive alla sessione

L'accoppiamento è uno stato persistente, non una stretta di mano che si dimentica dopo il test del cavo. La documentazione di debug di Android descrive il flusso wireless e osserva che la relazione dura finché non viene esplicitamente dimenticata o le autorizzazioni non vengono revocate.

Controllate cosa è ancora autorizzato prima di dare la colpa al tunnel. Aprite Debug wireless, guardate Dispositivi accoppiati e dimenticate tutto ciò che non riconoscete più. Eseguite adb devices dalla workstation per vedere quali voci rispondono ancora, e adb disconnect per eliminarne una obsoleta. Disattivare il debug wireless chiude del tutto la porta in ascolto.

Su una rete condivisa o non attendibile, lasciatelo disattivato. Un'autorizzazione persistente su una rete che non controllate è un problema più grande di un'ipotetica elusione del TUN.

Prima di segnalare quel bug

Un rapporto utile nomina il confine esatto che ha fallito. Includete modello del dispositivo e versione di Android, client VPN e versione, se il blocco era attivo, pacchetto dell'app e UID, e la rete su cui si trovava il telefono. Aggiungete il comando o la richiesta che ha prodotto l'osservazione, oltre all'ora in cui è avvenuta. Senza questo, nessuno può riprodurre il confine che dichiarate rotto.

Non disattivate l'applicazione delle regole e non esponete il debug su una rete non attendibile per rendere il test più scenografico. Questo cambia il sistema che state misurando e lascia prove che nessuno può ripetere.

Se la vostra unica prova è che ADB si è connesso mentre la VPN era attiva, avete misurato il percorso sbagliato. Rieseguite prima il test a livello di app; la risposta di solito arriva lì.