Por que um curinga numa diretiva route do OpenVPN não pode funcionar

a rota instala prefixos de endereço, então um padrão de nome de host não tem com o que coincidir. Use um prefixo para redes e um proxy ou arquivo PAC quando os domínios precisarem decidir.

A intenção é razoável: enviar tudo de um domínio da empresa pelo túnel e deixar o resto em paz. A diretiva que está sendo editada instala rotas, e uma rota não tem qualquer conceito de nome de host com que coincidir. Toda tentativa de escrever um curinga nela produz ou um erro de análise ou, pior, uma rota que hoje funciona por acaso porque o nome foi resolvido para um único endereço. Dois mecanismos diferentes estão sendo solicitados a fazer o trabalho um do outro.

O que uma rota instala e o que ela nunca lê

Uma entrada de rota diz que um prefixo de destino é alcançável por uma interface. O kernel compara os pacotes com esses prefixos, então os únicos identificadores envolvidos são endereços e máscaras. Um nome de host nunca aparece na decisão de encaminhamento, e é por isso que um padrão não pode ser comparado ali.

OpenVPN pode aceitar um nome resolvível em alguns parâmetros de rota, e essa tolerância é uma fonte de confusão. O nome é resolvido enquanto a configuração é aplicada, produzindo um ou mais endereços que se tornam rotas comuns. Depois disso, o nome desaparece completamente da imagem.

Então uma rota construída a partir de um nome é um instantâneo, não uma regra. Ela cobre aquilo a que esse nome se resolveu no momento em que o túnel começou, e esse é exatamente o comportamento que você não quer para uma família de hosts que muda. Um registro que se move amanhã deixa a rota apontando para ontem.

Quando o destino é realmente um prefixo

Se o alvo é uma rede privada conhecida, escreva o prefixo. Para um exemplo do espaço de documentação, um único host e uma sub-rede parecem assim:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Ambas as entradas nomeiam endereços e máscaras, e ambas sobrevivem a mudanças de DNS porque nada nelas depende de um nome. Essa é toda a vantagem: a rota é uma afirmação sobre topologia e não sobre uma busca que aconteceu uma vez.

Não extrapole um prefixo grande a partir de uma única resposta DNS. Um nome de host que se resolve num endereço não diz nada sobre o tamanho da rede por trás dele, e um prefixo adivinhado é a forma como um túnel acaba capturando tráfego que ninguém pretendia enviar por ele. Pergunte ao dono da rede qual é o prefixo real em vez de inferi-lo de uma busca.

Quando a unidade de trabalho é um nome de host

Selecionar por domínio exige algo que leia o domínio, ou seja, um componente da camada de aplicação. A resposta habitual é um proxy HTTP que fica do outro lado do túnel, com o cliente escolhendo quais pedidos enviar para ele.

Um arquivo de configuração de proxy pode expressar essa escolha. As regras ilustrativas abaixo enviam um domínio e seus subdomínios para um proxy e todo o resto direto:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

A comparação de nome exato cobre o próprio domínio, e a comparação de sufixo cobre os seus filhos sem corresponder a um nome que apenas termina em caracteres semelhantes. Ambas são necessárias, e omitir uma produz uma regra que parece correta e salta o vértice ou um impostor.

Estas regras escolhem um proxy; não o criam e não alteram nenhuma rota do sistema operacional. O endereço do proxy continua a precisar do seu próprio caminho pelo túnel, e os pedidos marcados como diretos seguem a política de encaminhamento que a máquina já tem.

O que a opção de proxy não cobre

Os programas que ignoram a configuração de proxy do navegador não serão afetados por nada disso. As ferramentas de linha de comando, os atualizadores e as aplicações com a sua própria pilha de rede usam a tabela de rotas, não o arquivo PAC, pelo que esses casos precisam de um mecanismo por aplicação suportado ou de outro desenho. Inventarie os clientes que importam antes de prometer que a regra do navegador cobre o fluxo de trabalho.

Voltar direto também não é uma via de escape. Se a política de encaminhamento da máquina já envia tudo para o túnel, um pedido marcado como direto permanece lá dentro, porque a escolha do proxy e a tabela de rotas são decisões diferentes tomadas em camadas diferentes.

A resolução de nomes é uma terceira questão separada. Escolher que pedidos vão para um proxy não diz nada sobre qual resolvedor lhes responde, e tratar as duas coisas como uma só configuração produz fugas que são invisíveis até alguém testar de fora. Decida onde cada consulta é respondida e escreva essa decisão ao lado da regra de proxy. Um resolvedor que muda porque o túnel subiu vai mover a resposta em silêncio.

Testar os dois caminhos, não apenas o feliz

Teste um nome de host que deveria coincidir, um nome de host que não deveria, e o vértice do domínio, já que o vértice é o caso mais frequentemente esquecido por uma regra apenas de sufixo. Depois confirme que caminho cada pedido realmente tomou em vez de inferi-lo do facto de a página ter carregado.

Por fim, teste o ramo de falha. Um proxy que não é alcançável deve falhar de uma forma que decidiu antecipadamente, em vez de voltar em silêncio para uma ligação direta. A referência de opções de rede documenta os parâmetros de rota com precisão; a metade de domínio deste desenho vive inteiramente fora dela.

Artigos relacionados