Um túnel compra topologia, não encriptação ou latência

O pressuposto é que um túnel é um cabo privado e rápido: constrói-se e o tráfego lá dentro fica encriptado, o caminho é mais curto e a ligação comporta-se como um cabo entre dois locais. Cada parte desse pressuposto é uma propriedade separada, e o túnel entrega apenas a primeira coisa que lhe foi pedida, ou seja, um caminho lógico. Tudo o resto tem de ser escolhido e configurado de propósito. Confundir as propriedades é como um projeto acaba com uma ligação encriptada que ninguém consegue diagnosticar e uma promessa de latência que ninguém consegue cumprir.

O mito: um túnel, três garantias

Um túnel faz uma coisa de forma fiável. Faz com que dois extremos que não estão ligados diretamente se comportem como se fossem adjacentes para algum propósito, enquanto a rede intermédia transporta os pacotes externos. Isso é uma alteração de topologia, e é realmente útil por si só.

A encriptação, o transporte de protocolos e o isolamento do encaminhamento são decisões separadas sobrepostas. Um túnel GRE não tem nenhuma das três no sentido criptográfico, e um túnel IP-in-IP é um desenho válido sem qualquer confidencialidade. Nenhum deles é um erro; são túneis a fazer exatamente o que os túneis fazem. A etiqueta no diagrama não diz que propriedades estão presentes.

Depois de separar as propriedades, as perguntas tornam-se respondíveis: este túnel transporta uma adjacência de encaminhamento, transporta tramas, esconde os endereços internos, promete algo sobre o atraso? São quatro respostas diferentes com quatro consequências de configuração diferentes.

O que o túnel acrescenta realmente ao mapa

Os extremos obtêm um caminho que antes não tinham. Se esse caminho se comporta como um salto encaminhado ou como um segmento Ethernet depende inteiramente do encapsulamento, e a diferença muda o que os dois locais podem fazer com ele. Um túnel encaminhado dá-lhe um próximo salto e um prefixo; uma extensão Ethernet dá-lhe comportamento de difusão e um domínio de falha muito maior.

Um túnel IP não torna automaticamente o local remoto parte da mesma sub-rede, nem faz correr um protocolo de encaminhamento através dele, a menos que a implementação suporte essa adjacência. O multicast é outra pergunta separada com a sua própria 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

Esses comandos respondem a partes diferentes da pergunta. O primeiro diz que tipo de interface existe, o segundo diz que caminho o kernel escolheria, e os dois últimos mostram o comportamento real da camada inferior em vez da promessa da etiqueta.

O transporte é uma decisão separada da alcançabilidade

Um túnel pode transportar um protocolo que a camada inferior não encaminha. IPv6 sobre um caminho IPv4 é o caso clássico, e funciona porque os extremos compreendem as duas famílias enquanto os routers entre eles só precisam de entregar os pacotes externos. A camada inferior precisa de um caminho funcional até ao extremo do túnel e nada mais.

Os extremos, no entanto, precisam de suporte completo: encaminhamento, endereços e uma aplicação que use realmente a família interna. Atribuir um prefixo IPv6 a um túnel não torna um serviço que só funciona com IPv4 alcançável por IPv6, nem torna a camada inferior de dupla pilha.

O transporte de tramas é um compromisso maior do que o transporte de protocolos. Estender um domínio de difusão por um túnel desloca consigo o comportamento de spanning tree, ARP e a propagação de falhas, o que é uma decisão de desenho e não um interruptor de funcionalidade.

O isolamento não é confidencialidade

As VPN de fornecedor mantêm as rotas e o tráfego dos clientes em contextos de encaminhamento separados, e essa separação é real e valiosa. Não é encriptação. A especificação de BGP/MPLS VPN diz explicitamente que a sua privacidade vem do modelo de encaminhamento e não da criptografia, e é exatamente a distinção que se perde num diapositivo que só diz VPN.

Se precisa de confidencialidade, precisa de um mecanismo criptográfico com autenticação e gestão de chaves, e precisa de saber onde termina. Um túnel que proporciona separação e um túnel que proporciona encriptação podem ser o mesmo túnel, mas só quando alguém configurou ambos.

A consequência prática é que «está numa VPN» responde a uma pergunta sobre o contexto de encaminhamento e não lhe diz nada sobre quem pode ler os bytes no caminho. Duas equipas podem ter ambas razão e ainda assim descrever coisas diferentes. Quando surgir a pergunta de segurança, pergunte onde termina a criptografia e o que autentica os pares, não se existe um túnel.

A latência e a QoS seguem a camada inferior

Uma extremidade lógica não é um caminho físico mais curto. Os pacotes externos continuam a atravessar as mesmas ligações, filas e fornecedores, e o encapsulamento acrescenta sobrecarga por pacote mais processamento nas duas pontas. Um túnel pode ser rápido porque a camada inferior é boa, nunca porque é um túnel.

O tratamento da qualidade de serviço é pior do que isso, porque depende de domínios administrativos que pode não controlar. As marcações internas têm de ser mapeadas para as externas deliberadamente, e cada fornecedor no caminho tem de oferecer o tratamento que espera. A encriptação não cria prioridade; esconde o campo que um equipamento intermédio poderia ter usado para classificar o fluxo.

Meça a camada inferior antes de prometer alguma coisa. Um relatório que mostra atraso estável e nenhuma perda no caminho externo é prova; um diagrama com um túnel em cima não é.

Escolha o túnel para a relação de rede de que precisa e depois especifique separadamente a encriptação, a política de acesso, o tamanho dos pacotes e o desempenho. Quatro decisões, quatro provas e nenhuma etiqueta única que substitua qualquer delas.