[PATCH 0/5] Improvements to "connection" tracking for UDP
We need rudimentary "connection" tracking for UDP because we do have a many-to-one mapping for our few NAT cases. This is handled by the port flags. We can make some simplfiications to this code for clarity. David Gibson (5): udp: Don't attempt to translate a 0.0.0.0 source address udp: Small streamline to udp_update_hdr4() udp: Implement IPv6 PORT_GUA logic for IPv4 as well udp: Clarify connection tracking flags udp: Remove PORT_ADDR_SEEN "connection" tracking mode udp.c | 69 +++++++++++++++++++++++++++++++---------------------------- 1 file changed, 36 insertions(+), 33 deletions(-) -- 2.40.1
If an incoming packet has a source address of 0.0.0.0 we translate that to
the gateway address. This doesn't really make sense, because we have no
way to do a reverse translation for reply packets.
Certain UDP protocols do use an unspecified source address in some
circumstances (e.g. DHCP). These generally either require no reply, a
multicast reply, or provides a suitable reply address by other means.
In none of those cases does translating it in passt/pasta make sense. The
best we can really do here is just leave it as is.
Signed-off-by: David Gibson
Streamline the logic here slightly, by introducing a 'src' temporary for
brevity. We also transform the logic for setting/clearing PORT_LOOPBACK.
This makes udp_update_hdr4() more closely match the corresponding logic
from udp_update_udp6().
Signed-off-by: David Gibson
For IPv6 UDP, the PORT_GUA flag is set for a port when we get a
"connection" from ip6.addr, that is from the host's global address. An
exactly analogous situation is possible for IPv4, but we don't handle it
the same way. In practice it will only show up if addr_seen is different
from addr, which is unusual. Nonetheless we should handle this the same
way for IPv4 and IPv6.
Signed-off-by: David Gibson
The PORT_LOCAL, PORT_LOOPBACK and PORT_GUA flags in udp_tap_port are a
rudimentary form of "connection" tracking for UDP. We need this because
there are several remote source addresses that we have to translate to the
gateway address when we present packets to the guest. We need these flags
to work out which address to translate that gateway address back to for
reply packets.
The flags are confusing, though, it's not really clear what each one means
individually, and LOCAL and LOOPBACK are only ever tested in combination.
Really, it all boils down to just 3 options:
- Packets from addr_seen got tanslated
- Packets from (host side) loopback got translated
- Packets from addr got translated
Replace the flags with an enum explicitly giving those options.
Signed-off-by: David Gibson
The mode of UDP NAT represented by PORT_ADDR_SEEN isn't actually useful.
In most cases addr_seen and addr will be the same, in which case it's just
redundant with PORT_ADDR. If they are different, that means the guest is
using an address different from the one it's been assigned. The natural
consequence of doing that is that you can't communicate with some other
host which is using the address you squatted. We don't need to shield
the guest from the consequences of shooting itself in the foot this way.
Signed-off-by: David Gibson
On Wed, May 17, 2023 at 03:05:24PM +1000, David Gibson wrote:
We need rudimentary "connection" tracking for UDP because we do have a many-to-one mapping for our few NAT cases. This is handled by the port flags. We can make some simplfiications to this code for clarity.
I'm planning to subsume these patches in a broader reaching NAT cleanup, so no need to pay too much attention to them. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
participants (1)
-
David Gibson