☰

RHEL/CentOS Agora para adicionar regras nftáveis ​​ao firewalld na inicialização do sistema?

tag-icon • tag-icon firewalld nftables
RHEL/CentOS Agora para adicionar regras nftáveis ​​ao firewalld na inicialização do sistema?

Estou usando o firewalld no RHEL 8 e preciso adicionar algumas regras nftáveis ​​também.

(As regras nftáveis ​​são baseadas na resposta aCentOS 8 como roteador NAT com nft e firewalld - como fazer com que ele passe TFTP?)

Em um firewall em execução, isso funciona bem com o comando nft -f.

No entanto, isso se perde na reinicialização.

ODocumentação RedHat(atrás do acesso pago) sugere o uso do serviço nftables.service para carregar regras na reinicialização, mas isso não funciona em conjunto com o firewalld. Os dois serviços estão listados como conflitantes e, mesmo que não estivessem, o firewalld provavelmente eliminaria as regras nftáveis.

Existe outra maneira de fazer com que as regras nftáveis ​​sejam carregadas na reinicialização?

Responder1

Ofirewalldutilitário, ao usar onftáveisProcesso interno,não irá liberar tabelas que não pertencem a ele:

Apenas libere as regras do firewalld

Como o nftables permite namespaces (por meio de tabelas)firewalld não faz mais uma limpeza completa das regras de firewall. Ele apenas liberará regras no firewalldmesa. Isso evita cenários em que regras de usuário personalizadas ou regras instaladas por outras ferramentas são eliminadas inesperadamente quando o firewalld foi reiniciado ou recarregado.

O mesmo deve ser feito ao gerenciar outras tabelas.

Na verdade na resposta anterior já está feito: onftáveisregras exclui idempotentementeapenassua própria mesa: handletftp.

Infelizmente, esse não é o caso para nftables.serviceopararAção:

ExecStop=/sbin/nft flush ruleset

É preciso apenas garantir que a parte stop do serviço systemd não libere diretamente todas as regras enquanto ainda faz o trabalho. Este trabalho será delegado em funcionários dedicadosnftáveisregras para opararAção.

Então aqui está um método prático: duplique (por exemplo systemctl cat nftables.services:) e altere nftables.servicepara uma versão instanciada [email protected]para ser colocada :/etc/systemd/system/[email protected]

[Unit]
Description=Idempotent nftables rules for %I
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ProtectSystem=full
ProtectHome=true
ExecStart=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# As the rules are idempotent, ExecReload is same as ExecStart
ExecReload=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# The stop rules should only have the first boilerplate parts
ExecStop=/sbin/nft -f /etc/nftables/idempotent/stop-%I.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Crie o diretório de configuração dedicado usado acima:

mkdir -p /etc/nftables/idempotent

Coloque regras que para cada tabela definida sempre comecem assim, portanto o carregamento das regras é independente de outras tabelas eidempotente(exemplo com tabelas ip fooe bridge bar):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

table ip foo {
    ...
}

table bridge bar {
    ....
}

ou apenas use uma tabela por arquivo. A flush rulesetdeclaração é proibida porque é global.

A razão pela qual uma tabela é criada, excluída e recriada é para obter o resultado idempotente: embora excluir uma tabela inexistente seja um erro e faria atomicamente todo o carregamento falhar, declarar uma tabela existente sem defini-la (adicionando uma tabela vazia) nunca falha e não faz nadaexceto criá-lo vaziose não existisse antes. Em ambos os casos (não existia na inicialização, existe na recarga)excluiragora pode funcionar, deixando o local para realmente definir a tabela logo em seguida. Tudo isso está acontecendo na mesma transação e ainda é atômico: nenhum pacote será avaliado com falta.ip footabela se ela existisse antes durante isso.

Prepare umpararversão acima que só será deletada (aqui as declarações vazias não são estritamente necessárias e poderiam ser removidas se houvesse apenas uma tabela, mas devem ser mantidas se houver mais de uma tabela: a falha é para toda a transação):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

e coloque tudo em seu local:

/etc/nftables/idempotent/foobar.nft
/etc/nftables/idempotent/stop-foobar.nft

Agora isso pode ser ativado com:

systemctl enable --now local-idempotent-nft@foobar

Exemplo da pergunta anterior do OP:

em /etc/nftables/idempotent/handletftp.nft:

table ip handletftp
delete table ip handletftp

table ip handletftp {
    ct helper helper-tftp {
        type "tftp" protocol udp
    }

    chain sethelper {
        type filter hook forward priority 0; policy accept;
        ip saddr 192.168.1.0/24 ip daddr 10.0.10.10 udp dport 69 ct helper set "helper-tftp"
    }
}

Em/etc/nftables/idempotent/stop-handletftp.nft

table ip handletftp
delete table ip handletftp

Habilitando e iniciando:

systemctl enable --now local-idempotent-nft@handletftp

Parando:

systemctl stop local-idempotent-nft@handletftp

que vai sairfirewalldregras em vigor. Da mesma forma, parar ou reiniciarfirewallddeixará essas regras em vigor.

Provavelmente há melhorias a serem feitas:

  • nftáveistem umincluirdeclaração que poderia ser usada de alguma forma para evitar a duplicação do padrão.
  • o exemplo específico sobre TFTP depende de nf_nat_tftpcujo carregamento não será feito automaticamente (ao contrário do nf_conntrack_tftpque é carregado automaticamente a partir de referência nas regras ou contrário aofirewalldque carregaria nf_nat_tftpexplicitamente). Tão relacionado, mas não estritamentenftáveisas configurações devem ser mantidas em mente (esta configuração pode simplesmente ser inserida /etc/modules-load.d/).

informação relacionada