Mantenha a política do nftables estável enquanto a interface VPN chega

Os túneis são descartáveis; a política não deveria ser. Num gateway Linux, uma regra do nftables que corresponde à interface do túnel pelo nome pode ser carregada uma vez e continua a aplicar-se sempre que essa interface aparece. A interface continua a ter um ciclo de vida: é criada, desaparece, e as rotas e traduções à sua volta seguem o seu próprio calendário. É a separação destes proprietários que mantém o acesso estável durante uma reconexão.

Uma correspondência por nome sobrevive à interface

O nftables oferece correspondências numéricas por índice de interface e as correspondências dinâmicas por nome iifname e oifname. As regras que usam esses nomes carregam-se de forma limpa mesmo quando o dispositivo do túnel ainda não foi criado, que é exatamente o que um conjunto de regras precisa no arranque. A correspondência cessa se a interface for renomeada e recomeça quando uma nova interface assume esse nome. Um índice numérico não tem essa propriedade, por isso a forma nominal é a escolha habitual para um túnel.

O nome é uma chave de correspondência, não uma prova de quem está do outro lado. A autenticação do par continua a ser tarefa da VPN.

Leia a cadeia antes de acrescentar regras

Veja o que o conjunto de regras contém agora e onde ficaria uma regra nova, porque a ordem decide o resultado.

nft list ruleset
nft -c -f /etc/nftables.conf

A listagem mostra cadeias, regras e handles, e o modo de verificação valida um ficheiro candidato sem o carregar. Uma autorização apenas para o túnel colocada depois de uma aceitação anterior para o mesmo fluxo não muda nada, porque ganha a primeira regra correspondente. Por isso uma regra tardia pode parecer correta e não ter efeito nenhum. Leia a cadeia por ordem e confirme que a negação do tráfego do cliente para o link ascendente continua a preceder tudo o que seja mais amplo.

As rotas, a tradução e os fluxos têm outros proprietários

A presença da interface não cria rotas e não autentica o par. Isso pertence ao gestor da VPN, enquanto a tradução tem um terceiro ciclo de vida.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

A listagem do conntrack mostra os fluxos existentes com os seus valores originais e traduzidos, e a listagem de rotas mostra o que o gestor instalou para a interface. As regras NAT estabelecem o estado de seguimento de ligação no primeiro pacote, por isso um fluxo estabelecido conserva a sua tradução mesmo depois de a regra mudar. Por isso uma regra a ser atualizada e um fluxo que usa o caminho novo são afirmações diferentes. Decida que sessões têm de se reconectar e deixe em paz os fluxos não relacionados.

Aceite o arranque a frio, a perda e a recuperação

Teste o gateway com o túnel ausente no arranque, depois presente e depois após uma queda e um regresso. Confirme que o encaminhamento proibido continua negado enquanto falta o túnel, que um fluxo permitido novo funciona depois de o par ser autenticado e que a recuperação não exige limpar estado não relacionado. Não apague toda a cadeia POSTROUTING nem cada entrada de conntrack como ação de paragem de um perfil, porque outros serviços as partilham. Registe que componente alterou a interface, a rota e a política, em vez de apenas que um hook de arranque terminou com zero.

Uma política que sobrevive a uma reconexão é aquela cujos proprietários estão nomeados e cujas regras foram testadas com o túnel tanto em baixo como em cima. Um hook que relata sucesso só prova que o hook correu.