Como combinar reqid em nftables?

A versão nftables , 0.9.0, foi lançada em 2018-06-08 , há mais de um ano, e esse recurso não está disponível nesta versão. Apenas os testes que foram decapsulados estão disponíveis.

ATUALIZAÇÃO : nftables 0.9.1 foi lançado em 24/06/2019, então pode-se esperar que seja empacotado em sua distribuição favorita em breve.

Suporte de kernel para manipulação adicional de ipsec em nftables foi adicionado na versão 4.20 ¹ . No lado do usuário, o suporte correspondente para recursos ipsec adicionais foi adicionado nas ramificações git master por volta de 2018-09-21 para libnftnl ^{2 , 3} e nftables ^{4 , 5 , 6} .

O último patch é o que fornece reqid :

src: adicionar expressão ipsec (xfrm) Isso permite a correspondência em endereços de túnel/beet ipsec no estado xfrm associado a um pacote, id de solicitação ipsec e o SPI.

Exemplos:

ipsec in ip saddr 192.168.1.0/24
ipsec out ip6 daddr @endpoints
ipsec in spi 1-65536

(Bem, não há um exemplo para um ID de solicitação, nem corresponde ao protocolo subjacente que pode não ser implementado, veja mais tarde)

Portanto, para poder usar esse recurso, atualmente, pelo menos, é necessário:

• núcleo 4.20
• libnft 1.1.2 ou 1.1.3
• construa nftables a partir do git source . Um novo lançamento do nftables deve acontecer em breve , mas parece estar atrasado por enquanto.

Se a regra iptables do OP for um append em vez de uma exclusão (que atualmente só pode ser feita em nftables usando a palavra- chave handle ), ela deve ser traduzida para isso (incluindo o clichê):

nft add table ip filter
nft add 'chain ip filter forward { type filter hook forward priority filter; policy accept; }'
nft add rule ip filter forward ip saddr 10.0.0.1 iifname "eth0" ipsec in reqid 1 accept

Eu não adicionei meta ipsec existsantes ipsec in reqid 1: testar o reqid deve exigir e, portanto, testar já tendo sido sujeito a decapsulação ipsec.

O que parece não estar disponível e não mencionado na documentação é o equivalente a --proto esp, então não consegui colocar.

Se a correspondência do protocolo esp for realmente necessária, pode-se imaginar que usar uma marca no pacote do envelope externo deve fazê-lo, sabendo que a marca é preservada após a decapsulação:

nft add table ip filter
nft add 'chain ip filter input { type filter hook input priority filter; policy accept; }'
nft add 'chain ip filter forward { type filter hook forward priority filter; policy accept; }'
nft add rule ip filter input ip protocol esp meta mark set 1
nft add rule ip filter forward meta mark 1 ip saddr 10.0.0.1 iifname "eth0" ipsec in reqid 1 accept

Isenção de responsabilidade: leve com um grão de sal, apenas a sintaxe foi testada (usando nftables de git commit 01e5c6f0ed0315046537612f5a80e506d37a7f8e ). Isso não foi realmente verificado no IPSec. Provavelmente também há uma regra a ser adicionada para 4500/UDP para ESP encapsulado em UDP.

^{1 netfilter: nf_tables: adiciona expressão xfrm
2 expr: rt: ipsec match support
3 expr: adiciona suporte xfrm
4 src: rt: adiciona suporte para verificar se a rota irá realizar a transformação ipsec
5 src: renomeia meta secpath para meta ipsec
6 src: adiciona expressão ipsec (xfrm)}