OpenVPN TUN fronte a TAP: tres condicións que o deciden

Dous túneles poden transportar a mesma transferencia de ficheiros e ser completamente distintos no que poñen no cable. Un move paquetes IP entre dúas direccións; o outro move tramas Ethernet e pódese conectar en ponte a un segmento. Esa diferenza decide que aplicacións funcionan, que clientes poden conectarse e canto deseño de rede vas asumir.

Tres condicións resólveo na práctica. Trábaas en orde, porque a primeira adoita rematar a discusión.

Que transporta realmente cada interface

Un dispositivo TUN é unha interface punto a punto de capa 3: o núcleo entrégalle paquetes IP e o túnel lévaos ata unha dirección par. Un dispositivo TAP é unha interface de capa 2 que transporta tramas Ethernet, que é o que fai posible a ponte en absoluto, como describe a documentación do núcleo. Ningún dos dous cambia como se cifra a carga útil, e ningún é un axuste de forza. A elección trata sobre o que deben intercambiar os extremos, non sobre o ben que se protexe o tráfico.

Unha consecuencia séguese de inmediato: ambos os extremos deben estar de acordo. Un cliente configurado para un tipo de dispositivo non pode unirse a un servidor configurado para o outro, por moito que coincida todo o demais.

Condición un: precisa algo a capa dous?

A ponte xustifica a súa complexidade cando un protocolo necesita de verdade o mesmo dominio de difusión: tráfico que non sexa IP, descubrimento que non pode atravesar un router ou unha aplicación que insiste en estar nun mesmo segmento. Todo o demais é un problema de encamiñamento, e o encamiñamento resólveo con moita menos maquinaria. Estender un segmento por unha área extensa tamén estende as súas difusións, de modo que a prevención de bucles, a planificación de enderezos e os dominios de fallo pasan a formar parte do deseño. Iso é moito que aceptar para un requisito que unha soa ruta tería satisfeito.

A proba é concreta: nomea a aplicación que falla nun túnel encamiñado e di por que. Se a resposta é que precisa difusión, a capa dous é a resposta honesta. Se a resposta é que alguén non podía chegar a un servidor, o requisito é unha ruta ou unha regra de cortalumes.

Condición dous: poden os clientes?

O soporte non é uniforme. Os clientes de escritorio adoitan expoñer ambos os tipos de dispositivo, mentres que os clientes móbiles e integrados a miúdo só implementan o modo encamiñado, e un perfil que se importa sen queixas pode fallar igualmente cando tenta crear a interface. Comproba o cliente e a versión concretos en lugar de deducir as funcións do nome da plataforma.

Un erro de opción non admitida non é unha invitación a borrar liñas descoñecidas ata que a importación funcione. Significa que o perfil e o cliente non coinciden en que é posible, e a reparación corresponde ao operador que emitiu o perfil. Eliminar unha opción para calar un validador pode producir unha conexión que parece funcionar mentres omite en silencio a propiedade que existía para proporcionar.

Condición tres: é realmente unha cuestión de interface?

Dúas eleccións contiguas reciben a culpa dos problemas de interface. O dispositivo virtual decide que entra no túnel, mentres que UDP ou TCP decide como se comporta o transporte exterior, e ningún dos dous cura as transferencias que se atascan. Cando as transferencias grandes se colgan e as pequenas rematan, o tamaño dos paquetes e a MTU merecen a atención no seu lugar.

Un cliente que se conecta e despois non pode chegar a un servidor interno adoita estar mirando o encamiñamento, unha regra de cortalumes ou unha ruta de retorno que falta.

Para un servizo xestionado, usa a disposición de interfaces que especifica o perfil do operador, porque o lado do servidor xa está construído arredor dela. Para unha implantación privada, escolle a partir do requisito real da aplicación e escribe o motivo xunto á elección.

A cuestión non é que opción é máis forte. É cal necesita realmente o tráfico.