Faça a regra ip sobreviver a uma reconexão com o systemd-networkd

Adicione uma regra de política com ip rule e ela funciona até o link desaparecer; nesse momento simplesmente já não está lá. Nada falhou ruidosamente: o estado do kernel mudou e nenhum proprietário de configuração sabia que a regra devia existir. É toda essa a diferença entre uma regra que sobrevive e uma que não sobrevive. Num host com systemd-networkd, a solução é dar um proprietário à regra em vez de voltar a executar o comando após cada reconexão.

Uma regra só existe se alguém a possuir

A política de encaminhamento do kernel é estado, não configuração. Vive no sistema em execução, e tudo o que derrube a interface de que depende pode levá-la consigo. Um comando de shell muda esse estado e não deixa qualquer registo da intenção.

Os gestores de rede trabalham ao contrário: leem a configuração, aplicam-na e voltam a aplicá-la quando um evento de link invalida o estado anterior. Uma regra declarada na configuração deles é recriada, ao passo que uma regra acrescentada ao lado é um objeto estranho sem proprietário.

Essa distinção tem um nome no networkd, e vale a pena lê-lo antes de ativar seja o que for. As regras estranhas são removidas por omissão nas versões recentes, o que surpreende quem esperava que as suas entradas manuais persistissem.

Leia a versão antes de confiar numa definição

O comportamento de propriedade é controlado por uma definição no networkd.conf, e essa definição não existe nas versões antigas do systemd. Verifique a versão instalada antes de desenhar em torno dela, porque um host mais antigo comporta-se de forma diferente da documentação que está a ler.

Dois valores contam. Um decide se são removidas as regras não declaradas na configuração do networkd, e o outro faz o mesmo para as rotas. Ambos dizem respeito à propriedade e não ao conteúdo da política, e ambos escolhem por omissão o comportamento mais rigoroso nas versões atuais. Desativá-los globalmente mantém viva cada regra estranha, o que é uma decisão muito mais ampla do que declarar uma política VPN pretendida.

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

Esse grep diz-lhe o que está definido localmente e qual é a omissão do fornecedor. A ausência também é informação, porque significa que se aplica o valor compilado. Anote o valor por omissão para que a pessoa seguinte não tenha de o redescobrir.

Declare a regra e a tabela para a qual aponta

Uma regra num ficheiro .network nomeia uma tabela, e é tudo o que um nome faz. Não cria as rotas dentro dessa tabela nem verifica se fazem sentido. Declarar a regra sem as rotas produz uma política que faz corresponder o tráfego e depois o descarta.

Declare as rotas no mesmo ficheiro, com saltos seguintes alcançáveis e a tabela correta. Mantenha a prioridade na regra declarada para que caia onde espera na lista ordenada. Uma regra que chega à tabela errada mais cedo do que o previsto altera mais tráfego do que o serviço que queria reparar. Leia o fragmento abaixo como uma forma e não como um ficheiro completo, porque a propriedade da interface e o resto da ligação ainda têm de estar presentes.

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

Depois recarregue e leia o estado do kernel em vez do ficheiro. Uma configuração analisada de forma limpa pode ainda produzir uma regra que não pretendia, e as duas vistas só coincidem quando a declaração estava completa.

Escolha um único proprietário para a interface

Dois gestores num túnel produzem uma disputa que parece um erro em ambos. Importar uma configuração wg-quick existente para o networkd é uma migração e não um acrescento, e executar os dois deixa a interface e as suas regras sob dois proprietários.

Faça a migração de uma só vez: pare a unidade antiga, desative-a, declare a interface e as suas rotas no networkd e recarregue. Verifique que a unidade antiga não pode voltar no arranque. Uma unidade remanescente que se reativa após um reinício sobrescreve o estado que acabou de declarar. Guarde o ficheiro de configuração antigo até o novo ter sobrevivido a uma reconexão, e depois retire-o.

A propriedade da marca merece o mesmo cuidado: se uma regra corresponde a uma marca da firewall, algo tem de definir essa marca. Uma regra que se refere a uma marca que ninguém define é configuração morta que parece deliberada.

Ensaie os eventos do ciclo de vida

A configuração vale tanto quanto o seu comportamento ao longo dos eventos. Desligue o link, volte a ligá-lo, reinicie o serviço e renove o endereço. Depois de cada um, leia a lista de regras e o conteúdo da tabela.

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

O resultado pretendido é a mesma política com proprietário recriada e o estado obsoleto retirado, o que é mais duradouro do que voltar a acrescentar uma regra de shell após cada reconexão. Mantenha uma linha no registo de alterações que nomeie o ficheiro proprietário da regra e a versão que a suporta. Assim o engenheiro seguinte pode encontrar a política sem vasculhar um histórico de shell. Uma regra que ninguém possui é uma regra que voltará a perder-se.