Il tunnel diviso per i client hotspot non è un’esclusione per applicazione

Due requisiti che suonano equivalenti non lo sono: «escludi questa applicazione dalla VPN» e «manda questa unica destinazione fuori dalla VPN per il portatile sul mio hotspot». Il primo cambia come un socket sul telefono sceglie una rete. Il secondo deve cambiare una decisione di inoltro per un pacchetto arrivato da un altro dispositivo dopo che il telefono lo ha già accettato. Confondere i due è il modo in cui un client hotspot finisce con un’eccezione che è sempre valsa solo per il browser del telefono stesso.

Due sottosistemi possiedono le due domande

Android tiene separati la rete delle applicazioni e il tethering. I socket delle applicazioni vengono assegnati a una rete dallo stack di connettività, e un’applicazione VPN decide quali dei propri socket entrano nel tunnel. I pacchetti inoltrati da un client collegato sono gestiti dal sottosistema di tethering, che chiede a netd rotte, regole di policy e traduzione sull’interfaccia a valle.

L’esclusione per applicazione viene valutata quando un’applicazione apre un socket. Un pacchetto inoltrato non raggiunge mai quel controllo, perché non proviene da un socket di applicazione su questo dispositivo. È tutta la ragione per cui le due impostazioni non possono sostituirsi a vicenda, e non è un difetto in nessuna delle due.

Che cosa cambia davvero l’esclusione per applicazione

Un costruttore di VpnService può nominare i pacchetti che restano fuori dal tunnel con addDisallowedApplication, oppure nominare gli unici pacchetti ammessi all’interno con addAllowedApplication. Quelle applicazioni aprono allora socket sulla rete sottostante mentre la VPN continua a possedere la rotta predefinita per tutto il resto.

La portata è precisa: i socket propri del pacchetto, su questo dispositivo, finché il tunnel è attivo. Non dice nulla sul traffico inoltrato, nulla su un secondo dispositivo e nulla sui pacchetti che il sistema invia per conto del tethering.

Non è nemmeno un controllo di destinazione. Escludere un browser esclude ogni indirizzo che quel browser raggiunge, compreso quello che volevate tenere dentro il tunnel. Quando il requisito nomina una destinazione invece di un’applicazione, il selettore di applicazioni è lo strumento sbagliato per costruzione.

Che aspetto ha un pacchetto in tethering per il telefono

Il pacchetto del client arriva sull’interfaccia hotspot con un indirizzo di origine privato assegnato dal telefono, diciamo 192.168.43.20, e una destinazione pubblica. Per inoltrarlo il telefono ha bisogno di una rotta verso un collegamento a monte e di una regola di traduzione perché le risposte trovino la via di ritorno, dato che l’indirizzo privato del client non significa nulla sulla rete cellulare.

Android esprime questo con regole di policy che selezionano una tabella di routing, e netd ricostruisce le tabelle e le regole pertinenti quando reti e VPN cambiano. Un numero di tabella, una priorità di regola o un nome di interfaccia copiati da un post di un forum, o dallo stesso modello in una versione più vecchia, non stabiliscono una proprietà duratura. Quella ricostruzione è anche il motivo per cui una regola scritta a mano può funzionare per un’ora e fermarsi dopo la riconnessione successiva.

La policy di cui un’eccezione hotspot ha davvero bisogno

Scrivete la decisione come origine, destinazione e percorso previsto prima di toccare una regola. La forma minima per una destinazione approvata è questa:

Entrambe le direzioni devono essere complete. Il ramo diretto ha bisogno di una rotta utilizzabile attraverso il collegamento a monte cellulare che risulta attuale; il ramo VPN ha bisogno della rotta del tunnel più il permesso di inoltrare. Qualsiasi traduzione di origine deve corrispondere all’uscita scelta, perché il NAT applicato a un’interfaccia di tunnel presenta l’indirizzo del tunnel e non quello cellulare, e il percorso di ritorno non concorda allora con il percorso di andata.

Le risposte devono raggiungere lo stesso client a valle tramite stato tracciato o una rotta esplicita, e un contatore di pacchetti in uscita non ne prova nulla. Tenete anche il trasporto esterno proprio della VPN fuori dalla portata dell’eccezione, altrimenti i pacchetti portanti del tunnel ereditano una policy scritta per una richiesta web di un client.

Un indirizzo catturato non è una destinazione

Un solo indirizzo IPv4 letto da un browser è un’istantanea. I servizi grandi rispondono da anycast o da un insieme rotante di indirizzi di bordo, molti sono a doppio stack, e un flusso di accesso può toccare host di autenticazione e telemetria che la pagina non mostra mai. Un’eccezione costruita intorno all’indirizzo che avete visto per caso si rompe la volta successiva che il servizio riequilibra.

Usate gli indirizzi documentati dal proprietario del servizio, o un intervallo che pubblica, e considerate entrambe le famiglie di indirizzi. Se il requisito non può essere espresso come insieme stabile, è probabilmente una questione di policy per il servizio e non un trucco di routing su un telefono.

Verificate dal lato a valle

Tre controlli, in questo ordine: il servizio scelto dal portatile, una destinazione ordinaria che deve restare dentro la VPN e un’applicazione del telefono che deve restare intatta. Poi ripetete dopo una riconnessione e dopo un cambio di collegamento a monte, perché è allora che le tabelle di policy vengono ricostruite.

Se l’implementazione di condivisione del telefono non riesce a tenere quel contratto durante una riconnessione, spostate la policy selettiva su un router a valle supportato invece di accumulare regole root sul dispositivo. Un router può esprimere la corrispondenza di origine e destinazione con un proprietario stabile, e la documentazione del modulo di tethering è il riferimento giusto per ciò che il telefono fa davvero.