Un túnel compra topoloxía, non cifrado nin latencia

A suposición é que un túnel é un cable privado e rápido: constrúese e o tráfico interior queda cifrado, a ruta é máis curta e a ligazón compórtase como un cable entre dous sitios. Cada parte desa suposición é unha propiedade separada, e o túnel entrega só o primeiro que se lle pediu, que é unha ruta lóxica. Todo o demais hai que elixilo e configuralo a propósito. Confundir as propiedades é como un deseño acaba cunha ligazón cifrada que ninguén pode diagnosticar e unha promesa de latencia que ninguén pode cumprir.

O mito: un túnel, tres garantías

Un túnel fai unha cousa de forma fiable. Fai que dous extremos que non están conectados directamente se comporten como se fosen adxacentes para algún propósito, mentres a rede intermedia transporta os paquetes externos. Iso é un cambio de topoloxía, e é realmente útil por si só.

O cifrado, o transporte de protocolos e o illamento do reenvío son decisións separadas que se colocan enriba. Un túnel GRE non ten ningunha das tres no sentido criptográfico, e un túnel IP-in-IP é un deseño válido sen ningunha confidencialidade. Ningunha das dúas cousas é un erro; son túneles facendo exactamente o que fan os túneles. A etiqueta do diagrama non lle di que propiedades están presentes.

Unha vez que separa as propiedades, as preguntas vólvense respondibles: este túnel transporta unha adxacencia de encamiñamento, transporta tramas, oculta os enderezos internos, promete algo sobre o retardo? Son catro respostas diferentes con catro consecuencias de configuración diferentes.

Que engade realmente o túnel ao mapa

Os extremos obteñen unha ruta que antes non tiñan. Que esa ruta se comporte como un salto encamiñado ou como un segmento Ethernet depende por completo da encapsulación, e a diferenza cambia o que os dous sitios poden facer con ela. Un túnel encamiñado dálle un seguinte salto e un prefixo; unha extensión Ethernet dálle comportamento de difusión e un dominio de fallo moito maior.

Un túnel IP non converte automaticamente o sitio remoto en parte da mesma subrede, nin fai que un protocolo de encamiñamento corra a través del salvo que a implementación admita esa adxacencia. O multicast é outra pregunta aparte coa súa propia resposta.

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

Eses comandos responden a partes distintas da pregunta. O primeiro di que tipo de interface existe, o segundo di que ruta escollería o núcleo, e os dous últimos mostran o comportamento real da capa inferior en lugar da promesa da etiqueta.

O transporte é unha decisión separada da alcanzabilidade

Un túnel pode transportar un protocolo que a capa inferior non reenvía. IPv6 sobre unha ruta IPv4 é o caso clásico, e funciona porque os extremos entenden ambas familias mentres que os encamiñadores intermedios só necesitan entregar os paquetes externos. A capa inferior necesita unha ruta funcional ata o extremo do túnel e nada máis.

Os extremos, con todo, necesitan soporte completo: reenvío, enderezos e unha aplicación que use realmente a familia interna. Asignar un prefixo IPv6 a un túnel non fai que un servizo que só funciona con IPv4 sexa alcanzable por IPv6, nin fai que a capa inferior sexa de dobre pila.

O transporte de tramas é un compromiso maior que o transporte de protocolos. Estender un dominio de difusión por un túnel traslada con el o comportamento de spanning tree, ARP e a propagación de fallos, o que é unha decisión de deseño e non un interruptor de función.

O illamento non é confidencialidade

As VPN de provedor manteñen as rutas e o tráfico dos clientes en contextos de reenvío separados, e esa separación é real e valiosa. Non é cifrado. A especificación de BGP/MPLS VPN di explicitamente que a súa privacidade vén do modelo de reenvío e non da criptografía, que é exactamente a distinción que se perde nunha diapositiva que só di VPN.

Se necesita confidencialidade, necesita un mecanismo criptográfico con autenticación e xestión de chaves, e necesita saber onde termina. Un túnel que proporciona separación e un túnel que proporciona cifrado poden ser o mesmo túnel, pero só cando alguén configurou ambos.

A consecuencia práctica é que «está nunha VPN» responde a unha pregunta sobre o contexto de encamiñamento e non lle di nada sobre quen pode ler os bytes na ruta. Dous equipos poden ter razón ambos e aínda así describir cousas distintas. Cando xurda a pregunta de seguridade, pregunte onde termina a criptografía e que autentica os pares, non se existe un túnel.

A latencia e a QoS seguen a capa inferior

Un bordo lóxico non é unha ruta física máis curta. Os paquetes externos seguen percorrendo as mesmas ligazóns, colas e provedores, e a encapsulación engade sobrecarga por paquete máis procesamento nos dous extremos. Un túnel pode ser rápido porque a capa inferior é boa, nunca porque sexa un túnel.

O tratamento da calidade de servizo é peor que iso, porque depende de dominios administrativos que quizais non controle. As marcas internas teñen que mapearse ás externas deliberadamente, e cada provedor da ruta ten que ofrecer o tratamento que vostede espera. O cifrado non crea prioridade; oculta o campo que un equipo intermedio podería ter usado para clasificar o fluxo.

Mida a capa inferior antes de prometer nada. Un informe que mostra retardo estable e ningunha perda na ruta externa é unha proba; un diagrama cun túnel enriba non o é.

Elixa o túnel para a relación de rede que necesita e despois especifique por separado o cifrado, a política de acceso, o tamaño de paquete e o rendemento. Catro decisións, catro probas e ningunha etiqueta única que substitúa ningunha delas.