Quem é dono do endereço, da rota, do DNS e do firewall numa VPN Linux?

Dois scripts a lutar pela mesma rota é a forma habitual de um problema de VPN Linux que fica registado como erro de encaminhamento. Um componente cria o dispositivo de túnel, outro acrescenta uma rota predefinida, um terceiro reescreve a configuração do resolvedor e um quarto recarrega as regras da firewall. Qualquer deles pode desfazer o trabalho de outro, e o vencedor é simplesmente quem correu por último. A pergunta que vale a pena responder não é que pacote instalar, mas que componente tem autoridade sobre cada parte do estado.

Escreva esse mapa uma vez, e a maioria das falhas de reconexão deixa de ser misteriosa. Quatro objetos importam: o dispositivo e os seus endereços, as rotas e as regras de política, a configuração de DNS e a firewall.

O dispositivo e os seus endereços

Um dispositivo de túnel é criado ou por um gestor que conhece o perfil, ou por um daemon que alguém iniciou à mão. Ambas as disposições funcionam sozinhas; misturá-las não. Se o NetworkManager possui o perfil, deixe que também possua o dispositivo, e não inicie um OpenVPN sem gestão contra o mesmo nome de túnel.

Anote quem remove o dispositivo quando a sessão termina. Um dispositivo que sobrevive à sua sessão é a fonte mais comum de endereços desatualizados e da confusão que se segue.

Rotas e regras de política

É nas rotas que os conflitos de propriedade causam danos visíveis. Um gestor de ligações instala uma rota predefinida para o túnel mais uma rota mais específica para a rede remota; depois um script escrito à mão acrescenta a sua própria rota predefinida com outra métrica e ganha ou perde em silêncio conforme o momento. Decida que entradas estão ligadas à ligação, quais são política permanente e que componente as atualiza após uma reconexão. Depois mantenha os outros componentes fora dessa tabela.

As regras de política merecem a mesma clareza, porque uma regra que aponta para uma tabela que ninguém preenche produz um buraco negro que parece exatamente um túnel morto. Se existe uma regra para forçar o tráfego para algum lado, a tabela que ela seleciona tem de ser mantida pelo mesmo dono.

O DNS é sempre um dono separado

Um daemon resolvedor corre como processo próprio sob a sua própria identidade, por isso não herda por acidente as decisões de encaminhamento do túnel. Quando a VPN empurra servidores DNS, algo tem de traduzir isso numa configuração por ligação que o resolvedor respeite, e algo tem de a retirar depois.

O mito aqui é que escrever um servidor de nomes no perfil muda para onde vão as consultas. Muda o que é dito ao resolvedor, não o socket que o resolvedor usa a montante. Teste com uma consulta mais uma procura de rota em vez de confiar no ficheiro.

O estado da firewall, e quem o restaura

As regras da firewall são o objeto mais vezes sobrescrito num anfitrião VPN. Um gestor pode acrescentar regras NAT ou de encaminhamento por ligação, enquanto um serviço de firewall no arranque recarrega um conjunto de regras guardado e apaga-as. Escolha uma só autoridade para a política e faça da outra sua consumidora, ou aceite que um reinício muda o comportamento em silêncio. As exceções ligadas à ligação pertencem a um ficheiro que o mesmo dono carrega, não a um comando iptables escrito durante a resolução de problemas.

Se as regras têm de sobreviver a uma reconexão, diga-o explicitamente. Se não têm, diga-o também, porque o próximo engenheiro vai assumir a resposta mais cómoda.

Ciclo de vida: arranque, reconexão, desmontagem

Dê um dono a cada um desses três momentos. No arranque, decida o que prepara os pré-requisitos e em que ordem. Num reinício suave, lembre-se de que o dispositivo pode sobreviver enquanto o estado da sessão não, por isso tem de correr um validador em vez de um criador. Na desmontagem, retira apenas o que esta ligação criou, porque repor todas as rotas ou esvaziar toda a firewall não é o mesmo que retirar um só túnel.

Para observação, ip monitor link address route mostra as alterações do kernel à medida que acontecem, mas relata eventos em vez de intenção: uma rota apagada não diz nada sobre que processo a apagou. Combine-o com o mapa de propriedade, e um encerramento confuso torna-se uma curta lista de candidatos.

As exclusões também têm um custo. Marcar toda uma classe de dispositivos como não gerida para escapar a um conflito entrega esse estado a ninguém, o que é uma decisão e não uma correção.