Túnel completo versus túnel dividido: as quatro diferenças

Os rótulos de túnel descrevem para onde vai o resto do tráfego de um portátil, não quão rápido ele vai. Com um túnel completo, os pedidos públicos atravessam o gateway VPN antes de saírem para a internet. Com um túnel dividido, os destinos privados usam o túnel e todo o resto segue o caminho local. Ambos chegam à aplicação interna, portanto o teste de alcance que as pessoas fazem primeiro não diz nada sobre qual política está implementada.

Teste a saída em vez disso: que endereço uma página de eco pública relata e qual resolvedor respondeu.

Mito: o túnel dividido é apenas a opção mais rápida

O túnel dividido é frequentemente vendido como uma funcionalidade de desempenho, e pode ser, mas isso é um efeito secundário e não a definição. A definição é uma decisão de encaminhamento sobre quais destinos entram no túnel. A diferença de velocidade só aparece quando o caminho direto é genuinamente melhor do que o desvio pelo escritório. Num link doméstico congestionado e num gateway pouco carregado, o túnel completo pode ser o mais rápido dos dois.

Portanto, o enquadramento honesto é sobre a propriedade e o controlo do caminho, com o desempenho como algo que se mede depois. Uma política escolhida por velocidade que move silenciosamente o seu DNS e a sua saída pública foi escolhida pelo motivo errado.

O que muda realmente: a saída

Num túnel completo, um site público vê o endereço de saída do escritório e a filtragem do escritório vê o pedido. Num túnel dividido, o mesmo site vê o endereço doméstico do utilizador e o escritório não vê nada. São modelos de visibilidade diferentes e nenhum é automaticamente mais seguro. A pergunta útil é qual deles a organização consegue realmente operar.

Verifique-o diretamente em vez de confiar num distintivo Ligado. Um eco de endereço público mostra a saída, e um teste de resolvedor mostra de quem era o DNS que respondeu.

O que o gateway tem então de transportar

Um gateway que transporta videochamadas, transferências e aplicações privadas precisa de capacidade para uma carga de trabalho muito diferente da de um que transporta apenas pedidos internos. A ligação à internet do site transporta tanto a chegada do utilizador como a saída pública subsequente, pelo que duas ligações podem saturar-se ao mesmo tempo.

A saída local remove essa carga e o desvio, e não garante uma melhor experiência, porque o caminho direto também pode estar congestionado. Compare a aplicação real em vez de tratar um rótulo de encaminhamento como uma medição de desempenho.

Existem exceções sob um túnel completo

Uma rota predefinida não é um inventário de cada pacote. Rotas mais específicas, permissões de rede local, exclusões de aplicações e regras IPv6 separadas movem todas tráfego, e é por isso que uma política descrita como túnel completo ainda pode fugar. A documentação de encaminhamento do sistema operativo faz essa distinção para as predefinições de túnel forçado, e a lista de exceções do cliente é onde a fuga costuma viver. Verifique o comportamento, não a intenção.

O IPv6 merece uma análise própria, porque um túnel que transporta apenas IPv4 deixa uma pilha inteira fora da política.

O DNS é uma política separada

Os nomes internos precisam de um resolvedor que os conheça, e esse resolvedor pode ser acessível apenas através do túnel. Um navegador com o seu próprio DNS encriptado pode contornar totalmente o resolvedor do sistema, o que produz uma divisão em que os nomes internos falham e os públicos funcionam, ou o contrário.

Decida para onde devem ir as consultas e depois faça o cliente e o navegador concordarem. A navegação pública bem-sucedida nunca testa a resolução de nomes internos, por isso é a prova errada a citar quando um site de intranet desaparece.

Escreva a política de falha e depois teste-a

Decida o que acontece quando o túnel cai: bloquear tudo, bloquear apenas recursos privados ou permitir ligações diretas. A reconexão automática não responde a essa pergunta, e um interruptor de emergência que cobre apenas a interface do túnel pode deixar as aplicações excluídas falar livremente. Teste uma desconexão real e uma mudança de rede e depois leia o estado do cliente, porque a documentação descreve o comportamento pretendido e não o instalado.

Registe as rotas privadas, a saída pública, os servidores DNS, as exceções locais e o comportamento em falha numa nota curta. É essa nota que torna a política verificável por alguém que não a escreveu.