☰

nftables 1:1 NAT (IP-Adresse zu IP-Adresse)

tag-icon • tag-icon linux networking iptables nat nftables
nftables 1:1 NAT (IP-Adresse zu IP-Adresse)

Upgrade auf Fedora 32, das mir völlig unbekannte nftables verwendet, und nachdem ich die gesamte Dokumentation durchgesehen habe, die ich finden konnte, kann ich nicht herausfinden, wie ich mein 1:1-NAT mit nftables replizieren kann, was bedeutet, dass mein Mailserver derzeit nicht erreichbar ist.

Ich habe diese Regeln mit Firewalld/iptables verwendet.

  <passthrough ipv="ipv4">-t nat -A PREROUTING -i eno1 -d public.ip -j DNAT --to-destination 10.99.99.21</passthrough>
  <passthrough ipv="ipv4">-t nat -A POSTROUTING -s 10.99.99.21 -o eno1 -j SNAT --to public.ip</passthrough>
  <passthrough ipv="ipv6">-t nat -A PREROUTING -i eno1 -d public.ipv6 -j DNAT --to-destination fdb9:b611:5d5d:ffff::21</passthrough>
  <passthrough ipv="ipv6">-t nat -A POSTROUTING -s fdb9:b611:5d5d:ffff::21 -o eno1 -j SNAT --to-source public.ipv6</passthrough>

Ich habe dies versucht, das scheint nicht zu funktionieren:

nft list table nat
table ip nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 10.99.99.21 oif "eno1" snat to public.ip
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                iif "eno1" ip daddr public.ip dnat to 10.99.99.21
        }
}

Weitere Informationen: Nach weiteren Nachforschungen stellt sich heraus, dass die SNAT-Regel aus irgendeinem Grund nicht übereinstimmt.

Antwort1

Ich werde meine eigene Frage beantworten, da ich sie nach einem Gespräch mit einem der Entwickler von Firewalld auf GitHub herausgefunden habe.

Das Problem besteht offenbar darin, dass sowohl nftables als auch iptables gleichzeitig verwendet werden.

Zitat:

This makes sense. It's due to the fact that iptables and nftables rules are executed independently inside the kernel/netfilter. So your scenarios are:

    iptables backend
        your direct rules accept the packets in the FORWARD chain
        further iptables rules in the FORWARD chain are not evaluated (due to accept)
        firewalld rules are part of iptables, so they're not considered (due to accept)
    nftables backend
        your direct rules accept the packets in the FORWARD chain
        further iptables rules in the FORWARD chain are not evaluated (due to accept)
        packet is now subject to firewalld's nftables ruleset, this happens even if the packet is accepted it iptables.
        zone is using "default" target, so packet is dropped in the FORWARD chain
        due to drop POSTROUTING (SNAT) is never reached

There is no fix possible as it's a result of how the kernel works. You can read more about this in the CAVEATS section of man page firewalld.direct.

Quelle:https://github.com/firewalld/firewalld/issues/708

Daher funktionieren die oben genannten nftables-Regeln, die über iptables-nft-Alternativen erstellt wurden, nicht, da sie immer noch den iptables-Kernelcode verwenden. Sie werden einfach auf nft angezeigt.

Detaillierte Erklärung zur Interaktion zwischen nftables und iptables hier: https://developers.redhat.com/blog/2020/08/18/iptables-die-zwei-varianten-und-ihre-beziehung-mit-nftables/

verwandte Informationen