Mantenha as rotas privadas e descarte o redirecionamento: túnel dividido OpenVPN

O túnel sobe, a aplicação carrega e então todo o resto no portátil começa a comportar-se de forma estranha. É essa a forma habitual de uma política só para redes privadas implementada ao apagar uma linha. Remover uma rota padrão empurrada muda de facto para onde vai o tráfego, mas não diz para onde o tráfego deveria ir em vez disso, e não toca de modo algum na resolução de nomes. Uma política precisa de duas metades positivas antes de poder ser testada.

Apagar o redirecionamento é apenas metade da alteração

Um redirecionamento de túnel completo e uma política só para redes privadas diferem naquilo que afirmam sobre o mundo. O redirecionamento reclama todos os destinos, enquanto a política privada reclama uma lista e deixa o resto em paz. Apagar a reivindicação sem escrever a lista produz um cliente que não chega a nada fora da LAN, o que parece uma falha de encaminhamento em vez de uma lacuna de política. Escreva a lista antes de remover a reivindicação, e a ordem desses dois passos deixa de importar.

Ambas as metades são requisitos e não valores padrão. Os prefixos privados têm de entrar no túnel, e os destinos comuns têm de conservar o caminho que tinham antes da ligação.

Se uma organização impõe o túnel completo, nada disto se aplica. O desenho só privado pertence a implementações em que o encaminhamento dividido está aprovado.

pull-filter é uma correspondência, não um interruptor

A diretiva pull-filter remove as opções empurradas cujos nomes correspondem a um prefixo, e é tudo o que faz. Ignorar o redirecionamento deixa cada outra opção empurrada no lugar, o que normalmente é o que se quer: as rotas, as definições de DNS e o valor da porta de ligação da rota continuam a chegar. Também não consegue remover uma diretiva escrita no perfil local, porque a filtragem se aplica ao que o servidor empurra.

Resista à tentação de ignorar todas as opções que começam por route. Esse padrão também descarta as rotas privadas de que a ligação precisa, e pode deixar cair informação de porta de ligação de que o túnel depende.

route-nopull é uma decisão mais ampla do que parece. Impede o cliente de aceitar as rotas empurradas e as opções ao estilo DHCP como grupo, o que é uma política diferente de filtrar uma única opção.

Escreva a lista de rotas da aplicação para fora

Comece pelo que o utilizador abre de facto e depois acrescente as peças de apoio. Uma aplicação em 10.60.20.15 implica a sua sub-rede 10.60.0.0/16, e um nome privado implica o resolver que lhe responde. Um utilizador que pediu uma única aplicação precisa, portanto, de dois destinos e de uma decisão de DNS. Tudo o que fica para além dessa lista está fora do âmbito por construção, e é isso que mantém a política verificável.

Num servidor que colabora, isso torna-se duas rotas empurradas, e nenhuma delas é um redirecionamento. Mantenha a topologia do túnel e os valores da porta de ligação da rota que o serviço existente fornece.

Quando só alguns utilizadores precisam desta política, aplique-a por cliente ou por grupo. Mudar o encaminhamento de todos para corrigir o requisito de uma só equipa é a forma como um túnel dividido se torna uma interrupção.

Faça o DNS seguir o mesmo caminho

Uma rota até ao resolver não é uma política de resolver. Num cliente systemd-resolved o resultado semântico é um domínio de encaminhamento para o espaço de nomes privado que aponta para o resolver interno, e é isso que faz com que só esses nomes o usem. Um cliente Windows precisa, em vez disso, do seu próprio mecanismo de política de espaços de nomes. Uma linha de servidor DNS no perfil não instala nenhuma das duas coisas por si só.

Verifique o que o sistema operativo selecionou e não o que o perfil pediu. No Linux, resolvectl status mostra o domínio e o servidor por ligação; no Windows, a tabela de políticas de espaços de nomes é a prova equivalente.

Mantenha o resolver acessível através do túnel, ou a política aponta para um endereço que não pode ser consultado. Um endereço de resolver a que o túnel não chega transforma uma política que funciona em tempo esgotado.

Verifique as duas metades numa reconexão

Volte a ligar o cliente depois da alteração e inspecione a rota efetiva para um endereço privado e para um público. Depois resolva um nome privado e um nome público e confirme que cada um usou o resolver previsto. O carregamento de um site público prova apenas a segunda metade, e é essa a metade que normalmente funciona por acaso.

Registe a política concluída numa frase: estes prefixos e nomes usam esta ligação, tudo o resto segue o caminho local. Depois guarde-a no perfil em vez de reparar as definições do adaptador após cada início de sessão.