OpenVPN TUN contra TAP: três condições que decidem

Dois túneis podem transportar a mesma transferência de ficheiro e ainda assim ser completamente diferentes no que colocam no cabo. Um move pacotes IP entre dois endereços; o outro move quadros Ethernet e pode ser ligado em bridge a um segmento. Essa diferença decide quais aplicações funcionam, quais clientes conseguem ligar-se e quanto desenho de rede está a assumir.

Na prática, três condições resolvem-no. Percorra-as por ordem, porque a primeira costuma encerrar a discussão.

O que cada interface transporta realmente

Um dispositivo TUN é uma interface ponto a ponto de camada 3: o kernel entrega-lhe pacotes IP e o túnel leva-os até um endereço par. Um dispositivo TAP é uma interface de camada 2 que transporta quadros Ethernet, e é isso que torna a bridge possível, como descreve a documentação do kernel. Nenhum deles altera a forma como a carga útil é cifrada, e nenhum é uma definição de força. A escolha é sobre o que os extremos têm de trocar, não sobre quão bem o tráfego está protegido.

Uma consequência surge de imediato: ambos os extremos têm de concordar. Um cliente configurado para um tipo de dispositivo não se pode juntar a um servidor configurado para o outro, por muito que o resto coincida.

Condição um: algo precisa da camada dois?

A bridge justifica a sua complexidade quando um protocolo precisa mesmo do mesmo domínio de difusão: tráfego que não seja IP, descoberta que não consegue atravessar um router ou uma aplicação que insiste em estar num só segmento. Tudo o resto é um problema de encaminhamento, e o encaminhamento resolve-o com muito menos maquinaria. Estender um segmento por uma área vasta estende também as suas difusões, pelo que a prevenção de ciclos, o planeamento de endereços e os domínios de falha passam todos a fazer parte do desenho. É muito para aceitar por um requisito que uma única rota teria satisfeito.

O teste é concreto: nomeie a aplicação que falha num túnel encaminhado e diga porquê. Se a resposta for que precisa de difusão, a camada dois é a resposta honesta. Se a resposta for que alguém não conseguia chegar a um servidor, o requisito é uma rota ou uma regra de firewall.

Condição dois: os clientes conseguem?

O suporte não é uniforme. Os clientes de ambiente de trabalho normalmente expõem ambos os tipos de dispositivo, enquanto os clientes móveis e embebidos muitas vezes implementam apenas o modo encaminhado, e um perfil que é importado sem queixas pode ainda falhar quando tenta criar a interface. Verifique o cliente e a versão concretos em vez de deduzir as funcionalidades a partir do nome da plataforma.

Um erro de opção não suportada não é um convite a apagar linhas desconhecidas até a importação passar. Significa que o perfil e o cliente não concordam sobre o que é possível, e a reparação pertence ao operador que emitiu o perfil. Remover uma opção para calar um validador pode produzir uma ligação que parece funcionar enquanto omite em silêncio a propriedade que existia para fornecer.

Condição três: isto é mesmo uma questão de interface?

Duas escolhas adjacentes levam a culpa por problemas de interface. O dispositivo virtual decide o que entra no túnel, enquanto UDP ou TCP decide como o transporte exterior se comporta, e nenhum deles cura transferências que ficam paradas. Quando as transferências grandes penduram e as pequenas passam, o tamanho do pacote e a MTU merecem a atenção.

Um cliente que se liga e depois não consegue chegar a um anfitrião interno está normalmente a olhar para o encaminhamento, uma regra de firewall ou um caminho de retorno em falta.

Num serviço gerido, use a disposição de interfaces que o perfil do operador especifica, porque o lado do servidor já está construído em torno dela. Numa implementação privada, escolha a partir do requisito real da aplicação e escreva o motivo junto da escolha.

A questão não é qual opção é mais forte. É qual é que o tráfego realmente precisa.