Konfigurationsfehler nach dem Aktualisieren von nftables

Question

Dies ist in einemNftables Skriptgeladen mit dem Befehl nft -f. Das nftWort hat darin keine Bedeutung und sollte nicht vorkommen. Aber es gibt 1 1/2 andere Probleme an der gleichen Stelle. Also mal sehen:

Um die Zeile, über die sich der nftBefehl beschwert, steht:

   chain forward {
       type filter hook forward priority 0;
       nft add rule inet filter forward ct status dnat accept;
       policy drop;
   }

nftentfernt werden,
bereits in einem inet filter forward(Ketten-)Block

Muss also add rule inet filter forwardauch entfernt werden. Eigentlich ;ist das überflüssig, da danach eine neue Zeile kommt.
```
       ct status dnat accept
```
policy drop;muss mit der Basiskettendefinition gesetzt werden

Diesmal mit seinem obligatorischen ;Teil der Syntax. Das policySchlüsselwort ist Teil derKetteDefinition, nicht Teil einerRegelDefinition. Dies scheint derzeit durch Regeln getrennt von der Basiskettendefinition akzeptiert zu werden, aber darauf kann man sich nicht verlassen: Dies könnte sich in einer späteren Version ändern.

Dasselbe gilt für die outputKette: Trennen Sie sie nicht policy accept;von ihrer Basiskettendefinition, damit Sie später nicht versehentlich Regeln dazwischen einfügen.

Die forwardKette sollte am Ende ersetzt werden durch:

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct status dnat accept
    }

Eine korrekte Syntax, aber nicht wirklich interessant, wäre es, die Regel nicht innerhalb der Blöcke, sondern vollständig außerhalb der Strukturen am Ende des Skripts zu definieren, und zwar wie folgt:

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}
add rule inet filter forward ct status dnat accept

Jedenfalls nft list rulesetwird es dann wieder wie zuvor im inet filter forwardKettenblock angezeigt.

Anmerkungen:

während es in Ordnung ist zu verwenden ip protocol icmp, ist es nicht in Ordnung zu verwendenip6 nexthdr ipv6-icmp

Der Grund dafür ist, dass im Gegensatz zu IPv4, wo das Protokoll im IPv4-Header immer das Layer-4-Protokoll ist, IPv6snächster Headerist nicht immer der Layer 4 (ICMP, UDP, TCP...) Header: es könnte stattdessen einErweiterungsheadererscheint zwischen dem IPv6-Header und dem Layer-4-Header (final). In diesem Fall trifft die Regel nicht zu.

Das Betriebssystem hat bereits ermittelt, zu welchem Layer-4-Protokoll dieses Paket gehört, daher sind die Informationen als Metainformationen und nicht als Paketinhaltsinformationen verfügbar: meta l4proto ipv6-icmp.

Das ist auchdokumentiert in der Manpage:

Dieser Ausdruck bezieht sich auf die IPv6-Headerfelder. Vorsicht bei der Verwendung ip6 nexthdr, der Wert bezieht sich nur auf den nächsten Header, d. h. er ip6 nexthdr tcpstimmt nur überein, wenn das IPv6-Paket keine Erweiterungsheader enthält. Pakete, die fragmentiert sind oder z. B. Routing-Erweiterungsheader enthalten, werden nicht abgeglichen. Verwenden Sie bitte , meta l4proto wenn Sie den echten Transportheader abgleichen und stattdessen alle zusätzlichen Erweiterungsheader ignorieren möchten.

Da die gleiche Zeile jedoch eine Zeile enthält icmpv6 type ..., wird das Layer-4-Protokoll bereits so gefiltert, dass es mit ICMPv6 übereinstimmt, und gleichzeitigDie Verwendung von ICMPv6 stellt das Layer-3-Protokoll implizit so ein, dass es mit IPv6 übereinstimmt.: Es ist überhaupt nichts nötig, um es richtig zu machen.

Aus den gleichen Gründen kann die vorherige Zeile auch ohne auskommen ip protocol icmp(ihr aktuelles Verhalten ist jedoch immer noch in Ordnung).

Die Linie:
```
        ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate over 10/second burst 4 packets drop
```
muss einfach ersetzt werden durch:
```
        icmpv6 type echo-request limit rate over 10/second burst 4 packets drop
```
(ohne dass ein vorangestellt werden muss meta nfproto ipv6 meta l4proto icmpv6)
TFTP
- TFTP verwendet nur UDP
  
  TCP-Port 69 wird nie verwendet und erfordert daher keine Regel, um ihn zuzulassen.
- TFTP und Stateful Firewall
  
  TFTPist ein Protokoll, das für Firewalls genauso schwierig ist wie FTP. Der Datentransfer selbst nutzt nach der ersten Abfrage nirgends mehr UDP-Port 69. Die angemessene Nutzung desTFTP-Conntrack-Helfermit zusätzlichen Regeln (die das nf_conntrack_tftpKernelmodul automatisch laden sollten) sollte wahrscheinlich erforderlich sein, es sei denn, die veraltete Sysctl-Einstellung net.netfilter.nf_conntrack_helperwurde wieder aktiviert.
  
  Es würde wirklich vom Thema abweichen, dies hier zu behandeln. Siehe den Anfang (nur) meiner Antwort aufCentOS 8 als NAT-Router mit nft und Firewalld – wie bringt man es dazu, TFTP zu bestehen?um einen Beispiel-TFTP-Regelsatz zu haben, der kopiert werden kann, um denFTP-Beispiel im nftables-Wiki.
Identische Regeln mit lediglich unterschiedlichen Portwerten können faktorisiert werden durchanonyme Sets.Nftables Version >= 1.0.2 hat sogar die -oOption (optimieren)um zu versuchen, dies automatisch zu tun.

Answer 1