TAP o TUN? Client OpenVPN per Android e server con bridge

Un profilo che funziona su un portatile fallisce sul telefono. La mossa ovvia è modificare una parola nella configurazione del client. Quella parola non aiuterà, perché le due estremità non parlano dello stesso tipo di traffico.

TAP trasporta frame Ethernet. TUN trasporta pacchetti IP. A un’app VPN Android viene consegnata un’interfaccia IP, il che rende possibile una delle due disposizioni e non l’altra, qualunque cosa dica la configurazione.

Il confronto è breve, ma decide se potete correggerlo sul telefono o dovete cambiare il servizio.

Due tipi di tunnel con carichi utili diversi

Un’interfaccia TAP si comporta come un adattatore Ethernet. Trasporta frame, cioè ARP, broadcast e tutto ciò che una LAN trasporta sotto IP. È questo che rende possibile il bridge: il tunnel estende un dominio di broadcast e i client si comportano come se fossero collegati a uno switch.

Un’interfaccia TUN trasporta pacchetti IP indirizzati a essa. Non c’è uno strato di collegamento da negoziare, né ARP, né broadcast. L’instradamento decide cosa entra nel tunnel, e la configurazione lato server usa una sottorete invece di un bridge.

Entrambe le estremità devono concordare quale delle due stanno facendo. Sostituire dev tap con dev tun su un lato non converte il servizio; produce un client che si aspetta un tunnel instradato e un server che spinge ancora frame, e la stretta di mano può riuscire mentre nulla di utilizzabile passa.

Cosa consegna davvero Android all’app

L’API VpnService della piattaforma dà a un’app un’interfaccia virtuale per i pacchetti IP, configurata con indirizzi, rotte e una MTU. In quell’API non c’è alcun adattatore Ethernet, né modo per l’app di inventarne uno.

Per questo OpenVPN Connect documenta il supporto per connessioni TUN instradate su Android invece del bridging TAP. Le domande frequenti su Android sono l’enunciato lato client di questo limite, e coincide con l’API della piattaforma.

Strumenti di rete con root, firmware personalizzato o un prodotto che implementa un livello di traduzione esplicito sono altre disposizioni. Il caso ordinario è quello su cui pianificare: un’app che può importare il vostro file e girare come utente normale, con un’interfaccia IP e nulla sotto di essa.

Com’è quando ci provate comunque

La connessione di solito si stabilisce. È questo che rende l’errore confuso: il client segnala connessione, il registro del server mostra un peer, e nessuna applicazione funziona.

Il traffico indirizzato all’indirizzo assegnato al telefono non arriva, perché il server fa bridging di frame verso un indirizzo MAC che il telefono non ha mai avuto. La scoperta dipendente dal broadcast resta vuota. Se la LAN dipende da DHCP attraverso il bridge, il telefono non otterrà un lease in quel modo, e un indirizzo assegnato a mano nella sottorete con bridge non crea comunque l’interfaccia mancante.

Alcuni client falliscono prima, all’importazione del profilo, quando vedono un tipo di dispositivo che non possono implementare. Entrambi i comportamenti significano la stessa cosa, e nessuno dei due si corregge aggiungendo rotte, cambiando il DNS o ampliando l’intervallo di indirizzi del tunnel.

Cosa deve cambiare il lato server

La correzione spetta a chi gestisce il servizio VPN, ed è di solito un’aggiunta più che una migrazione. Avviate una seconda istanza OpenVPN con un dispositivo instradato, la propria sottorete client e una configurazione lato server che assegna indirizzi e spinge le rotte che servono ai telefoni. L’istanza con bridge esistente continua a servire i dispositivi che hanno davvero bisogno di Ethernet.

Due dettagli lo rendono operativo in pratica. La LAN ha bisogno di una rotta di ritorno per la nuova sottorete client, che punta all’host VPN, altrimenti le risposte non torneranno mai. E il firewall sull’host del tunnel deve inoltrare tra l’interfaccia del tunnel e la LAN, ed è il passaggio che più spesso si dimentica quando un test dall’host stesso riesce.

Se l’operatore non può aggiungere un servizio, l’alternativa è un dispositivo che possa unirsi al bridge, cioè un portatile o un router che agisce per conto del telefono. È un aggiramento con il proprio costo di gestione, non una configurazione Android.

Decidete dall’applicazione, non dal tunnel

Chiedete a cosa deve arrivare davvero il telefono, poi mappatelo. Una condivisione file o un sito intranet raggiunto per nome o indirizzo è un requisito IP, e un tunnel instradato lo soddisfa una volta che il DNS risolve il nome e la rotta esiste. Uno strumento di scoperta che scorre il dominio di broadcast locale non è un requisito IP, e nessuna quantità di instradamento lo riempirà.

Quella tabella è anche la richiesta da inviare. Nominate l’applicazione, l’indirizzo o il nome che usa, e se dipende dalla scoperta. Un operatore può agire su quella descrizione, cosa che nessuno può fare su un telefono che non si connette.

Infine, mantenete il servizio TAP per i dispositivi che ne hanno bisogno invece di far imitare un adattatore LAN a ogni client. Due servizi con scopi chiari sono più facili da supportare di uno che funziona a metà per tutti.