¿TAP o TUN? Clientes OpenVPN para Android y servidores con puente

Un perfil que funciona en un portátil falla en el teléfono. El movimiento obvio es editar una palabra en la configuración del cliente. Esa palabra no ayudará, porque los dos extremos no hablan del mismo tipo de tráfico.

TAP transporta tramas Ethernet. TUN transporta paquetes IP. A una aplicación VPN de Android se le entrega una interfaz IP, lo que hace posible uno de esos dos arreglos y no el otro, diga lo que diga la configuración.

La comparación es breve, pero decide si puede arreglarlo en el teléfono o tiene que cambiar el servicio.

Dos tipos de túnel con cargas distintas

Una interfaz TAP se comporta como un adaptador Ethernet. Transporta tramas, es decir ARP, difusión y todo lo demás que una LAN transporta por debajo de IP. Eso es lo que hace posible el puente: el túnel extiende un dominio de difusión y los clientes se comportan como si estuvieran conectados a un conmutador.

Una interfaz TUN transporta paquetes IP dirigidos a ella. No hay capa de enlace que negociar, ni ARP, ni difusión. El enrutamiento decide qué entra en el túnel, y la configuración del servidor usa una subred en lugar de un puente.

Ambos extremos deben coincidir en cuál de las dos cosas hacen. Cambiar dev tap por dev tun en un lado no convierte el servicio; produce un cliente que espera un túnel enrutado y un servidor que sigue enviando tramas, y el saludo puede tener éxito mientras no pasa nada utilizable.

Qué entrega realmente Android a la aplicación

La API VpnService de la plataforma da a una aplicación una interfaz virtual para paquetes IP, configurada con direcciones, rutas y una MTU. En esa API no hay ningún adaptador Ethernet, ni forma de que la aplicación invente uno.

Por eso OpenVPN Connect documenta compatibilidad con conexiones TUN enrutadas en Android en lugar de puentes TAP. Las preguntas frecuentes de Android son la declaración del lado del cliente sobre ese límite, y coincide con la API de la plataforma.

Herramientas de red con root, firmware personalizado o un producto que implemente una capa de traducción explícita son otros arreglos. El caso ordinario es el que conviene planificar: una aplicación que pueda importar su archivo y ejecutarse como usuario normal, con una interfaz IP y nada por debajo.

Cómo se ve cuando lo intenta de todos modos

La conexión suele establecerse. Eso es lo que hace confuso el fallo: el cliente informa de conexión, el registro del servidor muestra un par, y ninguna aplicación funciona.

El tráfico dirigido a la dirección asignada al teléfono no llega, porque el servidor puentea tramas hacia una dirección MAC que el teléfono nunca tuvo. El descubrimiento que depende de la difusión queda vacío. Si la LAN depende de DHCP a través del puente, el teléfono no obtendrá una concesión por esa vía, y una dirección asignada a mano en la subred puenteada sigue sin crear la interfaz que falta.

Algunos clientes fallan antes, al importar el perfil, cuando ven un tipo de dispositivo que no pueden implementar. Cualquiera de los dos comportamientos significa lo mismo, y ninguno se corrige añadiendo rutas, cambiando el DNS o ampliando el rango de direcciones del túnel.

Qué tiene que cambiar el lado del servidor

La corrección corresponde a quien opera el servicio VPN, y normalmente es aditiva en lugar de una migración. Ejecute una segunda instancia de OpenVPN con un dispositivo enrutado, su propia subred de clientes y una configuración del lado del servidor que asigne direcciones y empuje las rutas que necesitan los teléfonos. La instancia puenteada existente sigue sirviendo a los dispositivos que de verdad necesitan Ethernet.

Dos detalles hacen que eso funcione en la práctica. La LAN necesita una ruta de retorno para la nueva subred de clientes, apuntando al host VPN, o las respuestas no volverán nunca. Y el cortafuegos del host del túnel debe reenviar entre la interfaz del túnel y la LAN, que es el paso que más a menudo se olvida cuando una prueba desde el propio host tiene éxito.

Si el operador no puede añadir un servicio, la alternativa es un dispositivo que pueda unirse al puente, es decir un portátil o un router que actúe en nombre del teléfono. Es un rodeo con su propio coste de gestión, no una configuración de Android.

Decida desde la aplicación, no desde el túnel

Pregunte a qué debe llegar realmente el teléfono y luego mapéelo. Un recurso compartido o un sitio de intranet al que se llega por nombre o dirección es un requisito IP, y un túnel enrutado lo satisface una vez que el DNS resuelve el nombre y la ruta existe. Una herramienta de descubrimiento que recorre el dominio de difusión local no es un requisito IP, y ninguna cantidad de enrutamiento lo llenará.

Esa tabla es también la petición que hay que enviar. Nombre la aplicación, la dirección o el nombre que usa, y si depende del descubrimiento. Un operador puede actuar sobre esa descripción, cosa que nadie puede hacer sobre un teléfono que no se conecta.

Por último, conserve el servicio TAP para los dispositivos que lo necesitan en lugar de hacer que cada cliente imite un adaptador de LAN. Dos servicios con propósitos claros son más fáciles de mantener que uno que funciona a medias para todos.