Atomic rule replacement: Difference between revisions
Jump to navigation
Jump to search
(Cleanup article: delete bits about format (moved to scripting). Clarify about versions. Put a single 'Notes' section. Don't talk about specific Debian versions, etc.) |
m (→Atomic Rule Replacement: rule-set -> ruleset) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 5: | Line 5: | ||
== Atomic Rule Replacement == | == Atomic Rule Replacement == | ||
You can use the ''-f'' option to atomically update your | You can use the ''-f'' option to atomically update your ruleset: | ||
<source lang="bash"> | <source lang="bash"> | ||
| Line 11: | Line 11: | ||
</source> | </source> | ||
Where ''file'' contains your | Where ''file'' contains your ruleset. | ||
You can save your | You can save your ruleset by storing the existing listing in a file, ie. | ||
<source lang="bash"> | <source lang="bash"> | ||
| Line 29: | Line 29: | ||
Please, take these notes into consideration: | Please, take these notes into consideration: | ||
* Table Creation: you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist. | * Table Creation: you may have to create the table with ''nft create table ip filter'' before you can load the file exported with ''nft list table filter > filter-table'' otherwise you will hit errors because the table does not exist. Newer nftables releases behave with more consistency regarding this. | ||
* Duplicate Rules: If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic | * Duplicate Rules: If you prepend the ''flush table filter'' line at the very beginning of the ''filter-table'' file, you achieve atomic ruleset replacement equivalent to what ''iptables-restore'' provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config. | ||
* Flushing Sets: ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (available since Linux 3.17 ) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions. | * Flushing Sets: ''flush table filter'' will not flush any sets defined in that table. To flush sets as well, use ''flush ruleset'' (available since Linux 3.17 ) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions. | ||
| Line 38: | Line 38: | ||
* What about flush statements in either, or neither file? If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. | * What about flush statements in either, or neither file? If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included. | ||
== See also == | |||
Some additional valuable information: | |||
* [[Scripting]] | |||
* [[Operations at ruleset level]] | |||
Latest revision as of 16:46, 13 February 2021
Warning about Shell scripting + nftables
With iptables it was common to use a bash script comprised of multiple iptables commands to configure a firewall. This is sub-optimal because it is not atomic, that is to say that during the few fractions of a second that your bash script takes to run your firewall is in a partially configured state. Nftables introduces atomic rule replacement with the -f option. This is different from bash scripts because nftables will read in all of the included config files, create the config object in memory alongside the existing config, and then in one atomic operation it swaps the old config for the new one meaning there is no moment when the firewall is partially configured.
Atomic Rule Replacement
You can use the -f option to atomically update your ruleset:
% nft -f file
Where file contains your ruleset.
You can save your ruleset by storing the existing listing in a file, ie.
% nft list table filter > filter-table
Then you can restore it by using the -f option:
% nft -f filter-table
Notes
Please, take these notes into consideration:
- Table Creation: you may have to create the table with nft create table ip filter before you can load the file exported with nft list table filter > filter-table otherwise you will hit errors because the table does not exist. Newer nftables releases behave with more consistency regarding this.
- Duplicate Rules: If you prepend the flush table filter line at the very beginning of the filter-table file, you achieve atomic ruleset replacement equivalent to what iptables-restore provides. The kernel handles the rule commands in the file in one single transaction, so basically the flushing and the load of the new rules happens in one single shot. If you choose not to flush your tables then you will see duplicate rules for each time you reloaded the config.
- Flushing Sets: flush table filter will not flush any sets defined in that table. To flush sets as well, use flush ruleset (available since Linux 3.17 ) or delete the sets explicitly. Early versions (Linux <=3.16) do not allow you to import a set if it already exists, but this is allowed in later versions.
- What happens when you include 2 files which each have a statement for the filter table? If you have two included files both with statements for the filter table, but one adds a rule allowing traffic from 192.168.1.1 and the other allows traffic from 192.168.1.2 then both rules will be included in the chain, even if one or both files contains a flush statement.
- What about flush statements in either, or neither file? If there are any flush commands in any included file then those will be run at the moment the config swap is executed, not at the moment the file is loaded. If you do not include a flush statement in any included file, you will get duplicate rules. If you do include a flush statement, you will not get duplicate rules and the config from *both* files will be included.
See also
Some additional valuable information: