Difference between revisions of "Talk:Nftables"

From ArchWiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==Future article updates==
+
==<s>Future article updates</s>==
 
I'm gonna be messing around with this page quite a bit in the coming weeks. The docs are pretty sparse, so it's gonna take some tinkering.
 
I'm gonna be messing around with this page quite a bit in the coming weeks. The docs are pretty sparse, so it's gonna take some tinkering.
  
 
--sudokode (2014-01-27 17:27:30 UTC)
 
--sudokode (2014-01-27 17:27:30 UTC)
 +
 +
==Bad practice and redundant code==
 +
Sitting beside the nftables maintainer, asking for feedback.
 +
 +
This page's sample rulesets could use a good cleanup. I'll do that soon.
 +
 +
TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:
 +
<pre>/* table of valid flag combinations - PUSH, ECE and CWR are always valid */
 +
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|
 +
                                TCPHDR_URG) + 1] =
 +
{
 +
        [TCPHDR_SYN]                            = 1,
 +
        [TCPHDR_SYN|TCPHDR_URG]                = 1,
 +
        [TCPHDR_SYN|TCPHDR_ACK]                = 1,
 +
        [TCPHDR_RST]                            = 1,
 +
        [TCPHDR_RST|TCPHDR_ACK]                = 1,
 +
        [TCPHDR_FIN|TCPHDR_ACK]                = 1,
 +
        [TCPHDR_FIN|TCPHDR_ACK|TCPHDR_URG]      = 1,
 +
        [TCPHDR_ACK]                            = 1,
 +
        [TCPHDR_ACK|TCPHDR_URG]                = 1,
 +
};
 +
</pre>
 +
 +
ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.
 +
 +
We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).
 +
 +
Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.
 +
 +
Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED.
 +
-- alp (2015-02-17
 +
 +
== <s>nft 0.7 warning entry</s> ==
 +
 +
Hey, thanks for discussion!
 +
 +
I've did research and now know what the issue is. I will replace the warning with a note.
 +
 +
For the config not working reason check out https://unix.stackexchange.com/questions/408497/nftables-configuration-error-conflicting-protocols-specified-inet-service-v-i?rq=1
 +
 +
Cheers,
 +
Hetti
 +
{{Unsigned|15:29, 5 February 2019 (UTC)|Hetti}}
 +
 +
== syntax improvements ==
 +
 +
I noticed there is a request to add '' italics for pseudo variables''. I am planning on doing that.
 +
 +
However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, {{ic|table inet filter}} I would change to {{ic|table inet ''my_filter''}}. Any objections?
 +
 +
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 01:41, 18 January 2020 (UTC)
 +
 +
: No, absolutely no objections. Though, my personal preference would be to stick to ''filter'' respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename ''my_filter'' to something sensible. [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 08:24, 18 January 2020 (UTC)
 +
 +
:I have no opinion on {{ic|filter}} vs {{ic|my_filter}}. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in [[nftables#top]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:09, 18 January 2020 (UTC)
 +
 +
: Exactly. '''filter''' is actually keyword in some statements. '''my_filter''' is not and probably never will be. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 20:36, 18 January 2020 (UTC)
 +
 +
:: Ok. I went over the page. Psedo variables are should be ''*_name'' or ''*_type''. The examples use my_* naming scheme for non key word arguments. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 23:37, 18 January 2020 (UTC)
 +
 +
::: For those wondering, like myself: this section probably related to [[special:diff/603849]]. Which is probably related to [[special:diff/595487]]. I think the section here should now be deleted, since it was resolved. Other than {{ic|filterName}} vs {{ic|my_filter}}, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think {{man|8|nft}} is using exactly what claimed here to be confusing. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 12:42, 3 April 2020 (UTC)
 +
 +
== Imperative vs Declarative syntax. ==
 +
 +
nftables supports two types of syntax.
 +
 +
Imperative. Used in {{ic|nft}} command, interactive mode and scripts:
 +
 +
{{ic|nft add table family_type table_name}}
 +
 +
can also be in the file with shebang
 +
 +
{{hc|somefile|
 +
#/usr/bin/nft -f
 +
add table ''family_type'' ''table_name''}}
 +
 +
Declerative. Only used in configuration:
 +
 +
{{bc|
 +
...
 +
table ''family_type'' ''table_name'' <nowiki>{</nowiki>
 +
    ...
 +
<nowiki>}</nowiki>}}
 +
 +
Right now the '''Configuration''' section only gives examples in the imperative syntax, however, '''Example''' section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.
 +
 +
So the '''Create table''' section would look like this:
 +
 +
==== Create table ====
 +
 +
The following adds a new table at run-time:
 +
 +
# nft add table ''family_type'' ''table_name''
 +
 +
Declaring table in configuration file:
 +
 +
{{bc|
 +
...
 +
table ''family_type'' ''table_name'' <nowiki>{</nowiki>
 +
    ...
 +
<nowiki>}</nowiki>}}
 +
 +
 +
I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.

Latest revision as of 12:42, 3 April 2020

Future article updates

I'm gonna be messing around with this page quite a bit in the coming weeks. The docs are pretty sparse, so it's gonna take some tinkering.

--sudokode (2014-01-27 17:27:30 UTC)

Bad practice and redundant code

Sitting beside the nftables maintainer, asking for feedback.

This page's sample rulesets could use a good cleanup. I'll do that soon.

TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:

/* table of valid flag combinations - PUSH, ECE and CWR are always valid */
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|
                                 TCPHDR_URG) + 1] =
{
        [TCPHDR_SYN]                            = 1,
        [TCPHDR_SYN|TCPHDR_URG]                 = 1,
        [TCPHDR_SYN|TCPHDR_ACK]                 = 1,
        [TCPHDR_RST]                            = 1,
        [TCPHDR_RST|TCPHDR_ACK]                 = 1,
        [TCPHDR_FIN|TCPHDR_ACK]                 = 1,
        [TCPHDR_FIN|TCPHDR_ACK|TCPHDR_URG]      = 1,
        [TCPHDR_ACK]                            = 1,
        [TCPHDR_ACK|TCPHDR_URG]                 = 1,
};

ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.

We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).

Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.

Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED. -- alp (2015-02-17

nft 0.7 warning entry

Hey, thanks for discussion!

I've did research and now know what the issue is. I will replace the warning with a note.

For the config not working reason check out https://unix.stackexchange.com/questions/408497/nftables-configuration-error-conflicting-protocols-specified-inet-service-v-i?rq=1

Cheers, Hetti —This unsigned comment is by Hetti (talk) 15:29, 5 February 2019 (UTC). Please sign your posts with ~~~~!

syntax improvements

I noticed there is a request to add italics for pseudo variables. I am planning on doing that.

However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, table inet filter I would change to table inet my_filter. Any objections?

Igo95862 (talk) 01:41, 18 January 2020 (UTC)

No, absolutely no objections. Though, my personal preference would be to stick to filter respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename my_filter to something sensible. Edh (talk) 08:24, 18 January 2020 (UTC)
I have no opinion on filter vs my_filter. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in nftables#top). -- nl6720 (talk) 10:09, 18 January 2020 (UTC)
Exactly. filter is actually keyword in some statements. my_filter is not and probably never will be. Igo95862 (talk) 20:36, 18 January 2020 (UTC)
Ok. I went over the page. Psedo variables are should be *_name or *_type. The examples use my_* naming scheme for non key word arguments. Igo95862 (talk) 23:37, 18 January 2020 (UTC)
For those wondering, like myself: this section probably related to special:diff/603849. Which is probably related to special:diff/595487. I think the section here should now be deleted, since it was resolved. Other than filterName vs my_filter, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think nft(8) is using exactly what claimed here to be confusing. Regid (talk) 12:42, 3 April 2020 (UTC)

Imperative vs Declarative syntax.

nftables supports two types of syntax.

Imperative. Used in nft command, interactive mode and scripts:

nft add table family_type table_name

can also be in the file with shebang

somefile
#/usr/bin/nft -f
add table family_type table_name

Declerative. Only used in configuration:

...
table family_type table_name {
    ...
}

Right now the Configuration section only gives examples in the imperative syntax, however, Example section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.

So the Create table section would look like this:

Create table

The following adds a new table at run-time:

# nft add table family_type table_name

Declaring table in configuration file:

...
table family_type table_name {
    ...
}


I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.