Hallo Andreas,
On Wed, Jan 26, 2022 at 21:41:43 +0100, Andreas Fett wrote:
ich hab mal ne nftables Frage in Bezug auf IPv4/IPv6 dualstack handling.
Man gibt dort ja in der table Definition inet, ip, ip6 an.
Wenn ich jetzt ne filter table mache für inet um tcp/udp und sowas zu handeln dann pack ich da ja typischerweise ne chain rein z.B. hook input und setz da ne policy drauf (aka drop) und dann den Regel Kram, der sowohl für IPv4 als auch für Ipv6 gelten soll.
Jetzt mach ich zusätzliche tables mit family ip und ip6 um Adressfamilien spezifischen Kram zu handeln (z.B. ICMP). Da pack ich nun wieder chains für hook input rein.
Muss ich da jetzt auch ne policy definieren?
Jede base-Chain (Chain, die an einen Hook gebunden ist) braucht eine priority und eine policy. Wenn Du keine policy angibst, bekommt sie trotzdem eine (accept).
Was wenn ich das nicht mache?
Wenn Du die priority weglaesst, gibt es einen Syntaxfehler. Die policy ist wie gesagt auch immer gesetzt.
greift dann die Policy von inet? Wie ist da die Präzedenz? Oder sind die priority Angaben global und gar nicht Table spezifisch?
Grundsaetzlich sind "inet" und "ip" unterschiedliche Tables, deren Chains aber ihre Hooks an den gleichen Stellen im Kernel haben koennen. Bei gemeinsam genutzten Hooks (etwa "input") greift die in der jeweiligen Chain angegebene priority. Diese ist meineswissens pro Hook global und steuert damit die Reihenfolge, in der die Chains in diesem Hook betrachtet werden.
------------------------------- #1 ------------------------------- flush ruleset table inet filter { chain input { type filter hook input priority 0; policy accept; tcp dport 80 log prefix "inet: " } } table ip filter { chain input { type filter hook input priority 0; policy accept; tcp dport 80 log prefix "ip: " } } ------------------------------------------------------------------
Hier ist fuer beide Chains priority 0 gesetzt. Damit haengt die Betrachtungsreihenfolge vermutlich nur von der Eintragereihenfolge ab. Die letzte (ip) kommt zuerst dran:
$ nc 127.0.0.1 80 $ dmesg [...] [ 2413.529970] ip: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14614 DF PROTO=TCP SPT=40931 DPT=80 WINDOW=65495 RES=0x00 SYN URGP=0 [ 2413.529985] inet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14614 DF PROTO=TCP SPT=40931 DPT=80 WINDOW=65495 RES=0x00 SYN URGP=0
------------------------------- #2 ------------------------------- flush ruleset table inet filter { chain input { type filter hook input priority 0; policy accept; tcp dport 80 log prefix "inet: " } } table ip filter { chain input { type filter hook input priority 100; policy accept; tcp dport 80 log prefix "ip: " } } ------------------------------------------------------------------
Jetzt wurde fuer die input-Chain in der ip-Table eine schlechtere priority (100) gesetzt, damit kommt "inet" zuerst dran:
$ nc 127.0.0.1 80 $ dmesg [...] [ 2583.027248] inet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48982 DF PROTO=TCP SPT=39143 DPT=80 WINDOW=65495 RES=0x00 SYN URGP=0 [ 2583.027264] ip: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48982 DF PROTO=TCP SPT=39143 DPT=80 WINDOW=65495 RES=0x00 SYN URGP=0
Und zu guter letzt... is das überhaupt die richtige Rangehensweise mit den drei Tables? Oder sollte man lieber alles in inet handeln und dann mit "meta nfproto" arbeiten?
Gute Frage. Es macht das Regelwerk u.U. uebersichtlicher. Aber Regeln, deren Statements (Aktionen) spezifisch fuer eine Adressfamilie sind, werden in "inet" wohl nicht funktionieren.
Gruss, Christian