Roteamento VPN por domínio versus rotas IP: qual se encaixa?

Uma rota IP corresponde a um prefixo de endereço, e o núcleo aplica-a sem fazer mais perguntas. Uma regra de VPN baseada em domínio corresponde a um nome, o que significa que algo na pilha tem de decidir que endereços esse nome designa neste momento e manter essa decisão atualizada. São mecanismos diferentes com modos de falha diferentes, e os fornecedores usam a mesma palavra para ambos. Compará-los em listas de funcionalidades perde o essencial; compare-os pelo que acontece quando a resposta muda.

A separação útil é entre uma regra que resolve e uma regra que não resolve.

Com o que cada regra realmente corresponde

Uma regra de prefixo corresponde a endereços de destino numa tabela de encaminhamento. Nada é resolvido, nada expira, e a correspondência é exata para cada pacote. Uma regra de domínio corresponde ao pedido de um nome por parte de uma aplicação, que RFC 1034 define como uma árvore de rótulos e não como um endereço. Alguns produtos resolvem o nome uma vez e instalam os endereços resultantes como rotas, o que transforma a regra numa regra IP com um temporizador de atualização acoplado.

Saiba qual dos dois tem antes de depurar, porque a falha parece completamente diferente em cada caso.

Onde vive a regra de domínio na pilha

Se o produto implementa regras de domínio através de um proxy local, o tráfego tem de chegar a esse proxy, e as aplicações que ignoram o proxy do sistema contornam a regra por completo. Se as implementa resolvendo nomes e acrescentando rotas, os endereços só estão tão frescos como a última atualização. Se se liga ao resolvedor, o comportamento do DNS passa a fazer parte da política de encaminhamento, e um resolvedor de reserva pode desfazê-lo em silêncio.

Leia o modelo do fornecedor e não a etiqueta da definição. Dois clientes com uma caixa chamada Split Tunnel podem estar a fazer três coisas diferentes.

Compare o que se parte

Três coisas partem-se de formas diferentes. Mudança de endereços: um nome de host de CDN pode resolver para um conjunto de endereços diferente em poucos minutos, pelo que uma lista copiada envelhece mal. Âmbito dos subdomínios: uma regra para example.com pode ou não cobrir api.example.com, e a documentação costuma ser explícita sobre qual. Falha de resolução: quando o resolvedor falha, um cliente que resolve pode recuar para o encapsulamento do tráfego ou para o envio direto.

Só a segunda é uma questão de configuração. As outras duas são questões de conceção sobre quanto o produto está disposto a adivinhar.

Quando o prefixo é a melhor resposta

Para uma sub-rede privada estável, um prefixo explícito é mais claro, mais rápido e mais fácil de auditar. Também sobrevive a uma falha do resolvedor, porque nada tem de ser resolvido. Recorra a uma regra de domínio quando o serviço está alojado, quando os endereços rodam ou quando realmente não consegue enumerar o conjunto de destinos. Não recorra a ela só porque o nome de host é aquilo que conhece por acaso.

Uma lista estática adivinhada é o pior dos dois: parece mantida e falha o tráfego em silêncio no dia em que o fornecedor acrescenta um host.

Verifique com um pedido novo

Teste com um pedido a frio após uma reconexão normal, porque uma página em cache pode nunca tocar na regra. Resolva o nome e depois verifique para onde foi realmente a ligação. dig +short app.example.com dá o conjunto de endereços atual, e a lista de ligações do cliente diz-lhe que interface transportou o fluxo.

Repita após o intervalo de atualização que o produto documenta. Se o conjunto de endereços se deslocar e a regra não o acompanhar, encontrou o comportamento real.

Mantenha também a política do resolvedor separada. Uma regra de domínio precisa de dados de nome corretos, mas não decide por si só que resolvedor responde à consulta.