TAP o TUN? Clients OpenVPN per a Android i servidors amb pont

Un perfil que funciona en un portàtil falla al telèfon. El moviment obvi és editar una paraula a la configuració del client. Aquesta paraula no ajudarà, perquè els dos extrems no parlen del mateix tipus de trànsit.

TAP porta trames Ethernet. TUN porta paquets IP. A una aplicació VPN d'Android se li lliura una interfície IP, cosa que fa possible un dels dos arranjaments i no l'altre, digui el que digui la configuració.

La comparació és curta, però decideix si ho podeu arreglar al telèfon o heu de canviar el servei.

Dos tipus de túnel amb càrregues diferents

Una interfície TAP es comporta com un adaptador Ethernet. Porta trames, és a dir ARP, difusió i qualsevol altra cosa que una LAN porti per sota d'IP. Això és el que fa possible el pont: el túnel estén un domini de difusió i els clients es comporten com si estiguessin endollats en un commutador.

Una interfície TUN porta paquets IP adreçats a ella. No hi ha cap capa d'enllaç per negociar, ni ARP, ni difusió. L'encaminament decideix què entra al túnel, i la configuració del servidor fa servir una subxarxa en lloc d'un pont.

Els dos extrems han d'acordar quina d'aquestes coses fan. Canviar dev tap per dev tun en un costat no converteix el servei; produeix un client que espera un túnel encaminat i un servidor que encara envia trames, i l'apretada de mans pot tenir èxit mentre no hi passa res d'utilitzable.

Què lliura realment Android a l'aplicació

L'API VpnService de la plataforma dona a una aplicació una interfície virtual per a paquets IP, configurada amb adreces, rutes i una MTU. En aquesta API no hi ha cap adaptador Ethernet, ni manera que l'aplicació n'inventi un.

Per això OpenVPN Connect documenta suport per a connexions TUN encaminades a Android i no per a ponts TAP. La pregunta freqüent d'Android és l'enunciat del costat del client sobre aquesta frontera, i coincideix amb l'API de la plataforma.

Eines de xarxa amb root, firmware personalitzat o un producte que implementi una capa explícita de traducció són arranjaments diferents. El cas ordinari és el que cal planificar: una aplicació que pugui importar el vostre fitxer i funcionar com a usuari normal, amb una interfície IP i res a sota.

Com es veu quan ho proveu igualment

La connexió normalment s'estableix. Això és el que fa confusa la fallada: el client informa de connexió, el registre del servidor mostra un parell, i cap aplicació funciona.

El trànsit adreçat a l'adreça assignada al telèfon no arriba, perquè el servidor fa pont de trames cap a una adreça MAC que el telèfon mai no ha tingut. El descobriment dependent de la difusió queda buit. Si la LAN depèn de DHCP a través del pont, el telèfon no obtindrà cap concessió per aquesta via, i una adreça assignada manualment a la subxarxa amb pont encara no crea la interfície que falta.

Alguns clients fallen abans, en importar el perfil, quan veuen un tipus de dispositiu que no poden implementar. Qualsevol dels dos comportaments vol dir el mateix, i cap dels dos no es resol afegint rutes, canviant el DNS o eixamplant el rang d'adreces del túnel.

Què ha de canviar el costat del servidor

L'arreglament correspon a qui gestiona el servei VPN, i normalment s'afegeix en lloc de migrar. Executeu una segona instància OpenVPN amb un dispositiu encaminat, la seva pròpia subxarxa de clients i una configuració del servidor que assigni adreces i empenyi les rutes que necessiten els telèfons. La instància amb pont existent continua servint els dispositius que realment necessiten Ethernet.

Dos detalls fan que això funcioni a la pràctica. La LAN necessita una ruta de retorn per a la nova subxarxa de clients, apuntant a l'host VPN, o les respostes no tornaran mai. I el tallafoc de l'host del túnel ha de reenviar entre la interfície del túnel i la LAN, que és el pas que més sovint s'oblida quan una prova des del mateix host té èxit.

Si l'operador no pot afegir un servei, l'alternativa és un dispositiu que es pugui unir al pont, és a dir un portàtil o un encaminador que actuï en nom del telèfon. És una solució temporal amb el seu propi cost de gestió, no una configuració d'Android.

Decidiu des de l'aplicació, no des del túnel

Pregunteu a què ha d'arribar realment el telèfon i després mapau-ho. Un recurs compartit o un lloc d'intranet al qual s'arriba per nom o adreça és un requisit IP, i un túnel encaminat el satisfà quan el DNS resol el nom i la ruta existeix. Una eina de descobriment que navega pel domini de difusió local no és un requisit IP, i cap quantitat d'encaminament no la omplirà.

Aquesta taula és també la petició que cal enviar. Anomeneu l'aplicació, l'adreça o el nom que fa servir i si depèn del descobriment. Un operador pot actuar sobre aquesta descripció, cosa que ningú no pot fer sobre un telèfon que no es connecta.

Finalment, manteniu el servei TAP per als dispositius que el necessiten en lloc de fer que cada client imiti un adaptador de LAN. Dos serveis amb propòsits clars són més fàcils de mantenir que un que funciona a mitges per a tothom.