The beginning of the end of iptables: Difference between revisions

Line 19:

from the userspace perspective, major advantages of nftables include the unified approach (no more IPv4/IPv6 duplication!) and the ability to monitor changes to the ruleset. from the developer's perspective, addition/deletion of rules now operates on a single rule at a time, rather than requiring a complete replacement of the ruleset to make any change.

so, for the majority of iptables users who are just <tt>DROP</tt>ping most incoming traffic and possibly jumping to <tt>MASQUERADE</tt> on an outgoing interface or two, maybe <tt>DNAT</tt>ting to a [[Docker]], the move to nftables has been entirely under-the-hood, and many were probably unaware of the switch. i've used <tt>nft</tt> a few times, but there's twenty-five years of <tt>iptables</tt> muscle memory present, so i've largely continued to make use of that model.

so, for the majority of iptables users who are just <tt>DROP</tt>ping most incoming traffic and possibly jumping to <tt>MASQUERADE</tt> on an outgoing interface or two, maybe <tt>DNAT</tt>ting to a [[Docker]], the move to nftables has been entirely under-the-hood, and many were probably unaware of the switch. i've used <tt>nft</tt> a few times, but there're twenty-five years of <tt>iptables</tt> muscle memory present, so i've largely continued to make use of that model.

recently, however, i've been trying to make more use of <tt>systemd-networkd</tt>. part of this was using <tt>IPMasquerade=ipv4</tt> in a <tt>systemd.network</tt> unit, rather than hooking an <tt>iptables -w -t nat -I POSTROUTING -o iface -j MASQUERADE</tt> to the interface in some ad hoc manner as i've always done (usually a <tt>pre-up</tt> rule in debian's <tt>/etc/network/interfaces</tt> or its non-union redhat equivalent). it worked just as expected, until i ran <tt>iptables -t nat -L -v -n</tt>:

@@ Line 19: / Line 19: @@
 from the userspace perspective, major advantages of nftables include the unified approach (no more IPv4/IPv6 duplication!) and the ability to monitor changes to the ruleset. from the developer's perspective, addition/deletion of rules now operates on a single rule at a time, rather than requiring a complete replacement of the ruleset to make any change.
-so, for the majority of iptables users who are just <tt>DROP</tt>ping most incoming traffic and possibly jumping to <tt>MASQUERADE</tt> on an outgoing interface or two, maybe <tt>DNAT</tt>ting to a [[Docker]], the move to nftables has been entirely under-the-hood, and many were probably unaware of the switch. i've used <tt>nft</tt> a few times, but there's twenty-five years of <tt>iptables</tt> muscle memory present, so i've largely continued to make use of that model.
+so, for the majority of iptables users who are just <tt>DROP</tt>ping most incoming traffic and possibly jumping to <tt>MASQUERADE</tt> on an outgoing interface or two, maybe <tt>DNAT</tt>ting to a [[Docker]], the move to nftables has been entirely under-the-hood, and many were probably unaware of the switch. i've used <tt>nft</tt> a few times, but there're twenty-five years of <tt>iptables</tt> muscle memory present, so i've largely continued to make use of that model.
 recently, however, i've been trying to make more use of <tt>systemd-networkd</tt>. part of this was using <tt>IPMasquerade=ipv4</tt> in a <tt>systemd.network</tt> unit, rather than hooking an <tt>iptables -w -t nat -I POSTROUTING -o iface -j MASQUERADE</tt> to the interface in some ad hoc manner as i've always done (usually a <tt>pre-up</tt> rule in debian's <tt>/etc/network/interfaces</tt> or its non-union redhat equivalent). it worked just as expected, until i ran <tt>iptables -t nat -L -v -n</tt>:

The beginning of the end of iptables: Difference between revisions

Dank (talk | contribs)