Quem deve ser dono das rotas e do DNS quando o openfortivpn se conecta?

Quatro etapas se empilham umas sobre as outras numa sessão de openfortivpn que funciona. O cliente autentica-se no gateway e inicia uma ligação TLS, depois executa PPP dentro dessa ligação, depois recebe um endereço e informações de DNS e, por fim, aplica rotas de host e definições do resolver. Cada etapa pode estar viva enquanto a seguinte não está, e é por isso que “ligado” é uma palavra tão escorregadia nas discussões de suporte.

A decisão que elimina a maior parte da confusão é quem é dono da última etapa. Ou o cliente VPN aplica ele mesmo as alterações no host, ou outro componente o faz, e misturar os dois a meio caminho é como as rotas e os ficheiros do resolver acabam a descrever sessões diferentes.

Quatro etapas que parecem uma única ligação

A primeira etapa é a admissão. um domínio de autenticação com nome ou um código de uso único, e recebe os parâmetros de que precisa para continuar. Quando o cliente imprime que está ligado ao gateway, isso significa que o transporte TLS está ativo. Não significa que o PPP negociou, e certamente não significa que uma aplicação interna esteja acessível.

A segunda etapa é o link PPP. O cliente inicia um processo PPP contra o dispositivo de túnel, e os dois lados negoceiam opções de link e endereços. Só depois disso o host sabe que endereços locais e remotos a sessão usa, e só então uma rota para o túnel pode fazer sentido.

A terceira etapa é aplicar essa informação ao host, e é aqui que a propriedade importa. O cliente pode acrescentar as rotas e reescrever a configuração do resolver, ou pode ser-lhe dito que recue e deixe ambas ao cuidado do que gerir a rede nessa máquina. O README do projeto descreve-as como responsabilidades separadas em vez de um único comportamento automático.

Quem edita a tabela de encaminhamento

Por predefinição, o cliente é o proprietário. Acrescenta uma rota para o gateway através da interface física, uma rota para o par do túnel e rotas para as redes que a sessão pode usar, e depois remove-as quando o processo termina. Essa predefinição é cómoda num portátil com um único gestor de rede e sem outro software VPN.

Escolha a entrega apenas quando outra coisa possui realmente o encaminhamento. Uma integração com o gestor de rede, um espaço de nomes de rede de contentor ou um agente de encaminhamento de todo o site podem já saber instalar e limpar os mesmos prefixos. Passar a opção no-routes impede então que dois escritores lutem pela mesma tabela, o que é uma corrida que se manifesta como perda intermitente de uma sub-rede em vez de uma falha limpa.

A sobreposição é a segunda razão para entregar. Se as rotas empurradas incluírem um prefixo que a rede local já usa, o cliente não pode resolver o conflito por si. Alguém tem de decidir se esse prefixo é alcançável pelo túnel, pela ligação física ou por uma rota mais específica, e essa decisão pertence a quem possui a topologia.

A limpeza é a terceira. Um cliente que falha antes de remover as suas rotas deixa um buraco negro que sobrevive à sessão, e a ligação seguinte pode acrescentar-lhe uma duplicação. Quem possui o encaminhamento também possui a verificação de que as entradas antigas desapareceram. Faça dessa verificação parte do caminho de arranque, não um passo de limpeza opcional.

Quem possui o DNS e o ficheiro do resolver

O DNS é a mesma decisão com arestas mais afiadas. O cliente pode aceitar os servidores DNS que o gateway ou o par PPP comunicam e escrevê-los na configuração do resolver do host. Numa máquina simples é exactamente o que quer, porque os nomes internos só se resolvem enquanto o túnel está ativo.

Num host Linux moderno o resolver pode ser gerido por um stub local, e reescrever o ficheiro do resolver por trás desse stub produz uma configuração que parece correta e se comporta de forma inconsistente. Se o host já executa um gestor de resolver, deixe-o possuir o DNS e alimente-o com os servidores do túnel através da sua interface suportada. A opção no-dns do cliente é a escolha correta aí, não um contorno.

O DNS dividido é uma questão separada de quem escreve o ficheiro. Enviar cada consulta pelo túnel é simples e lento; enviar só zonas internas por ele exige configuração por domínio que a maioria dos clientes simples não oferece. Decida que comportamento o host precisa antes de ativar as alterações do resolver do cliente. Uma escolha errada aqui parece uma falha de resolução de nomes mesmo quando o túnel está bem.

Privilégios, prontidão e a entrega

Criar o dispositivo de túnel e editar rotas do host ou o estado do resolver exige autoridade de rede elevada. O erro comum é concluir que, por isso, tudo deve correr como root, incluindo o navegador ou a aplicação que usa o túnel. Mantenha pequena a parte privilegiada: o cliente e o seu ficheiro de configuração, pertencentes a um administrador, enquanto as aplicações de utilizador mantêm a sua conta normal.

A prontidão deve ser definida por consumidor. Um supervisor pode considerar o serviço iniciado quando o processo do cliente está a correr e o dispositivo de túnel existe. Um trabalho de cópia de segurança só deve considerar a VPN utilizável quando o seu ponto de armazenamento responde pelo túnel. São verificações diferentes, e usar a mais fraca para o propósito mais forte produz trabalhos que começam demasiado cedo e falham de forma intermitente. Escreva a definição escolhida, porque um supervisor e um trabalho que não concordam sobre a prontidão são um ticket de suporte à espera de acontecer.

Teste o contrato com quatro observações: a fase do gateway conclui-se, o PPP atribui endereços, a rota pretendida está presente e um pedido a um host interno tem sucesso. Depois pare o cliente e confirme que cada uma dessas coisas foi removida ou restaurada. Se o host ainda resolve nomes internos ou ainda mantém uma rota depois de o túnel fechar, a entrega de propriedade está incompleta.