Inoltro di porte sull@APOS@hotspot Android: i tre punti di ingresso

Avete attivato l’hotspot, connesso la VPN, aperto una porta nell’app e l’altro dispositivo ancora non riesce a connettersi. Il pezzo mancante quasi mai è la porta stessa, ma la domanda su quale macchina possieda il socket in ascolto e quale indirizzo l’altro dispositivo debba raggiungere. Parto dal telefono verso l’esterno, perché lo schermo davanti a voi dice quale dei tre punti di ingresso state davvero provando.

Iniziate da dove il servizio gira davvero

Aprite l’app che deve accettare la connessione e leggete la sua pagina di stato. Se dice che è in ascolto, annotate l’indirizzo a cui è legata, perché quel singolo dettaglio decide la maggior parte dei casi qui sotto. Un’app legata a 127.0.0.1 è raggiungibile solo dal telefono, e non lo cambiano né il client dell’hotspot, né la traduzione dell’operatore, né l’uscita della VPN.

Poi confermate quale dispositivo esegue il servizio. Se è il telefono, il socket appartiene a quella app; se è un portatile dietro l’hotspot, ascoltatore e firewall appartengono al portatile e il telefono inoltra solo i pacchetti. Sono due progetti diversi, e mescolarli è il motivo per cui una porta aperta da una parte non fa nulla dall’altra.

In una build depurabile, adb shell elenca i socket tramite /proc/net/tcp, ma per la maggior parte delle persone lo stato dell’app stessa è la fonte onesta.

Primo punto di ingresso: un altro dispositivo sull’hotspot

È il caso locale e il più semplice. L’altro dispositivo raggiunge il telefono all’indirizzo che vede come proprio gateway, sulla porta su cui l’app ascolta, e nulla fuori dall’hotspot partecipa. Non serve alcuna traduzione dell’operatore, perché il traffico non lascia mai il segmento locale.

Due cose lo rompono: l’app legata al loopback, oppure la politica client del telefono che non consente la connessione locale. Provate con il protocollo proprio dell’applicazione invece di un TCP nudo, perché un ascoltatore che accetta e poi rifiuta da lontano sembra una porta chiusa.

Se il servizio gira su un portatile collegato, l’indirizzo hotspot del telefono non è affatto la destinazione; servono l’indirizzo del portatile sull’interfaccia hotspot e un ascoltatore lì.

Secondo punto di ingresso: il percorso dell’operatore

Raggiungere il telefono dalla rete mobile è un altro problema, e per IPv4 il più delle volte non funziona. Gli operatori mettono i dispositivi dietro una traduzione condivisa, ed è per questo che RFC 6598 riserva un intervallo di indirizzi condiviso proprio per quella disposizione. Una connessione in ingresso non richiesta non ha alcuna traduzione da cui arrivare, e nessuna configurazione locale ne crea una, perché il traduttore non è il vostro dispositivo.

L’accesso root non cambia nulla; dà il controllo dello stack del telefono, non del traduttore dell’operatore. Dove l’operatore offre un prefisso IPv6 pubblico può esistere un percorso in ingresso, ma ascoltatore e firewall hanno comunque bisogno di un’autorizzazione esplicita.

Terzo punto di ingresso: l’uscita della VPN

L’indirizzo che un sito riporta mentre il tunnel è attivo è l’indirizzo di uscita per il traffico in uscita coperto, non un indirizzo che accetta connessioni in ingresso a vostro nome. Usarlo verso l’interno richiede una funzione che il fornitore offra davvero, come una porta inoltrata o una mappatura in ingresso legata al vostro account, più un percorso utilizzabile dall’uscita al client.

Una regola locale di permesso non può fabbricare quella mappatura. Quello che fa è cambiare il percorso delle risposte dell’app, e questo conta quando l’app è esclusa dal tunnel: richiesta e risposta possono finire in contesti di rete diversi e la connessione fallisce come un problema di firewall.

Provate un solo percorso da un capo all’altro, poi nominate il proprietario

Scrivete la tupla prima di provare: sorgente prevista, indirizzo di destinazione, trasporto, porta e la macchina che possiede il socket in ascolto. Se un elemento è un’ipotesi, il test non vi dirà nulla di utile.

Poi provate quell’unico percorso autorizzato con l’autenticazione dell’app intatta. Non pubblicate un ascoltatore ampio e non disattivate controlli estranei solo per far rispondere un controllo ambiguo dell’indirizzo, perché entrambe le modifiche sopravvivono al test.

Il sottosistema di tethering di Android inoltra il traffico discendente su un percorso proprio, separato dalla normale cattura VPN, quindi un browser che funziona su un portatile collegato non dice nulla sull’accesso in ingresso a un servizio sul telefono. Prima di dire che funziona:

• L’ascoltatore è su un indirizzo che l’altra estremità può raggiungere, non sul loopback.
• L’altra estremità usa l’indirizzo di quel punto di ingresso, non l’indirizzo di uscita di una pagina di stato.
• Qualsiasi mappatura lato operatore o fornitore è una funzione supportata, non una regola aggiunta localmente.
• Richiesta e risposta passano per lo stesso contesto di rete, e l’autenticazione riesce ancora.