Un túnel compra topología, no cifrado ni latencia
Un túnel le da una ruta lógica y, quizá, un contexto de reenvío separado. No cifra por sí mismo ni promete latencia.
La suposición es que un túnel es un cable privado y rápido: se construye y el tráfico interior queda cifrado, la ruta es más corta y el enlace se comporta como un cable entre dos sedes. Cada parte de esa suposición es una propiedad separada, y el túnel entrega solo lo primero que se le pidió, que es una ruta lógica. Todo lo demás hay que elegirlo y configurarlo a propósito. Confundir las propiedades es como un diseño acaba con un enlace cifrado que nadie puede diagnosticar y una promesa de latencia que nadie puede cumplir.
El mito: un túnel, tres garantías
Un túnel hace una cosa de forma fiable. Hace que dos extremos que no están conectados directamente se comporten como si fueran adyacentes para algún propósito, mientras la red intermedia transporta los paquetes externos. Eso es un cambio de topología, y es realmente útil por sí solo.
El cifrado, el transporte de protocolos y el aislamiento del reenvío son decisiones separadas que se colocan encima. Un túnel GRE no tiene ninguna de las tres en el sentido criptográfico, y un túnel IP-in-IP es un diseño válido sin ninguna confidencialidad. Ninguna de las dos cosas es un error; son túneles haciendo exactamente lo que hacen los túneles. La etiqueta del diagrama no le dice qué propiedades están presentes.
Una vez que separa las propiedades, las preguntas se vuelven respondibles: ¿este túnel transporta una adyacencia de enrutamiento, transporta tramas, oculta las direcciones internas, promete algo sobre el retardo? Son cuatro respuestas diferentes con cuatro consecuencias de configuración diferentes.
Qué añade realmente el túnel al mapa
Los extremos obtienen una ruta que antes no tenían. Que esa ruta se comporte como un salto enrutado o como un segmento Ethernet depende por completo de la encapsulación, y la diferencia cambia lo que las dos sedes pueden hacer con ella. Un túnel enrutado le da un siguiente salto y un prefijo; una extensión Ethernet le da comportamiento de difusión y un dominio de fallo mucho mayor.
Un túnel IP no convierte automáticamente la sede remota en parte de la misma subred, ni hace que un protocolo de enrutamiento corra a través de él salvo que la implementación admita esa adyacencia. El multicast es otra pregunta aparte con su propia respuesta.
ip -d link show type gre ip route get 10.20.0.5 traceroute -n -T -p 443 10.20.0.5 mtr -n --report -c 20 10.20.0.5
Esos comandos responden a partes distintas de la pregunta. El primero dice qué tipo de interfaz existe, el segundo dice qué ruta elegiría el núcleo, y los dos últimos muestran el comportamiento real de la capa inferior en lugar de la promesa de la etiqueta.
El transporte es una decisión separada de la alcanzabilidad
Un túnel puede transportar un protocolo que la capa inferior no reenvía. IPv6 sobre una ruta IPv4 es el caso clásico, y funciona porque los extremos entienden ambas familias mientras que los enrutadores intermedios solo necesitan entregar los paquetes externos. La capa inferior necesita una ruta funcional hasta el extremo del túnel y nada más.
Los extremos, sin embargo, necesitan soporte completo: reenvío, direcciones y una aplicación que use realmente la familia interna. Asignar un prefijo IPv6 a un túnel no hace que un servicio que solo funciona con IPv4 sea alcanzable por IPv6, ni hace que la capa inferior sea de pila doble.
El transporte de tramas es un compromiso mayor que el transporte de protocolos. Extender un dominio de difusión por un túnel traslada con él el comportamiento de spanning tree, ARP y la propagación de fallos, lo que es una decisión de diseño y no un interruptor de función.
El aislamiento no es confidencialidad
Las VPN de proveedor mantienen las rutas y el tráfico de los clientes en contextos de reenvío separados, y esa separación es real y valiosa. No es cifrado. La especificación de BGP/MPLS VPN dice explícitamente que su privacidad viene del modelo de reenvío y no de la criptografía, que es exactamente la distinción que se pierde en una diapositiva que solo dice VPN.
Si necesita confidencialidad, necesita un mecanismo criptográfico con autenticación y gestión de claves, y necesita saber dónde termina. Un túnel que proporciona separación y un túnel que proporciona cifrado pueden ser el mismo túnel, pero solo cuando alguien ha configurado ambos.
La consecuencia práctica es que «está en una VPN» responde a una pregunta sobre el contexto de enrutamiento y no le dice nada sobre quién puede leer los bytes en la ruta. Dos equipos pueden tener razón ambos y aun así describir cosas distintas. Cuando surja la pregunta de seguridad, pregunte dónde termina la criptografía y qué autentica a los pares, no si existe un túnel.
La latencia y la QoS siguen a la capa inferior
Un borde lógico no es una ruta física más corta. Los paquetes externos siguen recorriendo los mismos enlaces, colas y proveedores, y la encapsulación añade sobrecarga por paquete más procesamiento en ambos extremos. Un túnel puede ser rápido porque la capa inferior es buena, nunca porque sea un túnel.
El tratamiento de calidad de servicio es peor que eso, porque depende de dominios administrativos que quizá no controle. Las marcas internas tienen que mapearse a las externas deliberadamente, y cada proveedor de la ruta tiene que ofrecer el tratamiento que usted espera. El cifrado no crea prioridad; oculta el campo que un equipo intermedio podría haber usado para clasificar el flujo.
Mida la capa inferior antes de prometer nada. Un informe que muestra retardo estable y ninguna pérdida en la ruta externa es una prueba; un diagrama con un túnel encima no lo es.
Elija el túnel para la relación de red que necesita y después especifique por separado el cifrado, la política de acceso, el tamaño de paquete y el rendimiento. Cuatro decisiones, cuatro pruebas y ninguna etiqueta única que sustituya a ninguna de ellas.