OpenVPN TUN frente a TAP: tres condiciones que lo deciden

Dos túneles pueden transportar la misma transferencia de archivos y diferenciarse por completo en lo que ponen en el cable. Uno mueve paquetes IP entre dos direcciones; el otro mueve tramas Ethernet y puede puentearse dentro de un segmento. Esa diferencia decide qué aplicaciones funcionan, qué clientes pueden conectarse y cuánto diseño de red estás asumiendo.

Tres condiciones lo resuelven en la práctica. Recórrelas en orden, porque la primera suele zanjar la discusión.

Qué transporta realmente cada interfaz

Un dispositivo TUN es una interfaz punto a punto de capa 3: el kernel le entrega paquetes IP y el túnel los lleva a una dirección par. Un dispositivo TAP es una interfaz de capa 2 que transporta tramas Ethernet, y eso es justo lo que hace posible el puenteo, como describe la documentación del kernel. Ninguno de los dos cambia cómo se cifra la carga útil, ni es un ajuste de fuerza. La elección tiene que ver con lo que los extremos deben intercambiar, no con lo bien protegido que esté el tráfico.

Una consecuencia se sigue de inmediato: ambos extremos deben coincidir. Un cliente configurado para un tipo de dispositivo no puede unirse a un servidor configurado para el otro, coincida lo que coincida.

Condición uno: ¿algo necesita la capa dos?

El puenteo se gana su complejidad cuando un protocolo necesita de verdad el mismo dominio de difusión: tráfico que no es IP, descubrimiento que no puede cruzar un router, o una aplicación que insiste en estar en un mismo segmento. Todo lo demás es un problema de enrutamiento, y el enrutamiento lo resuelve con mucha menos maquinaria. Extender un segmento por un área amplia también extiende sus difusiones, así que la prevención de bucles, el plan de direcciones y los dominios de fallo pasan a formar parte del diseño. Es mucho aceptar para un requisito que una sola ruta habría cubierto.

La prueba es concreta: nombra la aplicación que falla en un túnel enrutado y di por qué. Si la respuesta es que necesita difusión, la capa dos es la respuesta honesta. Si la respuesta es que alguien no podía llegar a un servidor, el requisito es una ruta o una regla de cortafuegos.

Condición dos: ¿pueden los clientes?

El soporte no es uniforme. Los clientes de escritorio suelen exponer ambos tipos de dispositivo, mientras que los clientes móviles e integrados a menudo implementan solo el modo enrutado, y un perfil que se importa sin quejarse puede fallar igualmente al intentar crear la interfaz. Comprueba el cliente y la versión concretos en lugar de deducir las capacidades del nombre de la plataforma.

Un error de opción no admitida no es una invitación a borrar líneas desconocidas hasta que la importación funcione. Significa que el perfil y el cliente no coinciden en lo que es posible, y la reparación corresponde al operador que emitió el perfil. Quitar una opción para callar a un validador puede producir una conexión que parece funcionar mientras omite en silencio la propiedad para la que existía.

Condición tres: ¿es esto realmente una cuestión de interfaz?

Dos elecciones vecinas reciben la culpa de los problemas de interfaz. El dispositivo virtual decide qué entra en el túnel, mientras que UDP o TCP decide cómo se comporta el transporte exterior, y ninguno de los dos cura las transferencias que se atascan. Cuando las transferencias grandes se cuelgan y las pequeñas funcionan, el tamaño de paquete y la MTU merecen la atención en su lugar.

Un cliente que se conecta y luego no alcanza un host interno suele estar mirando el enrutamiento, una regla de cortafuegos o una ruta de retorno ausente.

Para un servicio gestionado, usa la disposición de interfaces que especifica el perfil del operador, porque el lado del servidor ya está construido en torno a ella. Para un despliegue privado, elige a partir del requisito real de la aplicación y escribe el motivo junto a la elección.

La pregunta no es qué opción es más fuerte. Es cuál necesita realmente el tráfico.