TAP ou TUN? Clientes OpenVPN para Android e servidores con ponte

Un perfil que funciona nun portátil falla no teléfono. O movemento obvio é editar unha palabra na configuración do cliente. Esa palabra non axudará, porque os dous extremos non falan do mesmo tipo de tráfico.

TAP transporta tramas Ethernet. TUN transporta paquetes IP. A unha aplicación VPN de Android entrégaselle unha interface IP, o que fai posible un dos dous arranxos e non o outro, diga o que diga a configuración.

A comparación é curta, pero decide se pode arranxalo no teléfono ou ten que cambiar o servizo.

Dous tipos de túnel con cargas distintas

Unha interface TAP compórtase como un adaptador Ethernet. Transporta tramas, é dicir ARP, difusión e todo o demais que unha LAN transporta por baixo de IP. Iso é o que fai posible a ponte: o túnel estende un dominio de difusión e os clientes compórtanse coma se estivesen conectados a un conmutador.

Unha interface TUN transporta paquetes IP dirixidos a ela. Non hai capa de enlace que negociar, nin ARP, nin difusión. O encamiñamento decide que entra no túnel, e a configuración do servidor usa unha subrede en lugar dunha ponte.

Ambos extremos deben coincidir en cal das dúas cousas fan. Cambiar dev tap por dev tun nun lado non converte o servizo; produce un cliente que espera un túnel encamiñado e un servidor que segue enviando tramas, e o aperto de mans pode ter éxito mentres non pasa nada utilizábel.

Que entrega realmente Android á aplicación

A API VpnService da plataforma dá a unha aplicación unha interface virtual para paquetes IP, configurada con enderezos, rutas e unha MTU. Nesa API non hai ningún adaptador Ethernet, nin forma de que a aplicación invente un.

Por iso OpenVPN Connect documenta compatibilidade con conexións TUN encamiñadas en Android en lugar de pontes TAP. As preguntas frecuentes de Android son a declaración do lado do cliente sobre ese límite, e coincide coa API da plataforma.

Ferramentas de rede con root, firmware personalizado ou un produto que implemente unha capa de tradución explícita son outros arranxos. O caso ordinario é o que cómpre planificar: unha aplicación que poida importar o seu ficheiro e executarse como usuario normal, cunha interface IP e nada por baixo.

Como se ve cando o intenta de todos os xeitos

A conexión adoita establecerse. Iso é o que fai confuso o fallo: o cliente informa de conexión, o rexistro do servidor mostra un par, e ningunha aplicación funciona.

O tráfico dirixido ao enderezo asignado ao teléfono non chega, porque o servidor pontea tramas cara a un enderezo MAC que o teléfono nunca tivo. O descubrimento que depende da difusión queda baleiro. Se a LAN depende de DHCP a través da ponte, o teléfono non obterá unha concesión por esa vía, e un enderezo asignado a man na subrede ponteda segue sen crear a interface que falta.

Algúns clientes fallan antes, ao importar o perfil, cando ven un tipo de dispositivo que non poden implementar. Calquera dos dous comportamentos significa o mesmo, e ningún se corrixe engadindo rutas, cambiando o DNS ou ampliando o rango de enderezos do túnel.

Que ten que cambiar o lado do servidor

A corrección corresponde a quen opera o servizo VPN, e normalmente é engadida en lugar dunha migración. Execute unha segunda instancia de OpenVPN cun dispositivo encamiñado, a súa propia subrede de clientes e unha configuración do servidor que asigne enderezos e empurre as rutas que necesitan os teléfonos. A instancia ponteda existente segue servindo os dispositivos que de verdade necesitan Ethernet.

Dous detalles fan que iso funcione na práctica. A LAN necesita unha ruta de retorno para a nova subrede de clientes, apuntando ao host VPN, ou as respostas non volverán nunca. E a devasa do host do túnel debe reenviar entre a interface do túnel e a LAN, que é o paso que máis a miúdo se esquece cando unha proba desde o propio host ten éxito.

Se o operador non pode engadir un servizo, a alternativa é un dispositivo que poida unirse á ponte, é dicir un portátil ou un router que actúe en nome do teléfono. É unha volta cun custo de xestión propio, non unha configuración de Android.

Decida desde a aplicación, non desde o túnel

Pregunte a que debe chegar realmente o teléfono e despois mapéao. Un recurso compartido ou un sitio de intranet ao que se chega por nome ou enderezo é un requisito IP, e un túnel encamiñado sátao unha vez que o DNS resolve o nome e a ruta existe. Unha ferramenta de descubrimento que percorre o dominio de difusión local non é un requisito IP, e ningunha cantidade de encamiñamento o encherá.

Esa táboa é tamén a petición que hai que enviar. Nomee a aplicación, o enderezo ou o nome que usa, e se depende do descubrimento. Un operador pode actuar sobre esa descrición, algo que ninguén pode facer sobre un teléfono que non se conecta.

Por último, conserve o servizo TAP para os dispositivos que o necesitan en lugar de facer que cada cliente imite un adaptador de LAN. Dous servizos con propósitos claros son máis fáciles de manter ca un que funciona a medias para todos.