Le ven. 20 sept. 2024 à 19:03, Tiago Lam tiagolam@cloudflare.com a écrit :
sendmsg() doesn't currently allow users to set the src port from which egress traffic should be sent from. This is possible if a user wants to configure the src address from which egress traffic should be sent from
- with the IP_PKTINFO ancillary message, a user is currently able to specify a source address to egress from when calling sendmsg().
However, this still requires the user to set the IP_TRANSPARENT flag using setsockopt(), which happens to require special privileges in the case of IPv4.
To support users setting the src port for egress traffic when using sendmsg(), this patch extends the ancillary messages supported by sendmsg() to support the IP_ORIGDSTADDR ancillary message, reusing the same cmsg and struct used in recvmsg() - which already supports specifying a port.
Additionally, to avoid having to have special configurations, such as IP_TRANSPARENT, this patch allows egress traffic that's been configured using (the newly added) IP_ORIGDSTADDR to proceed if there's an ingress socket lookup (sk_lookup) that matches that traffic - by performing a reserve sk_lookup. Thus, if the sk_lookup reverse call returns a socket that matches the egress socket, we also let the egress traffic through - following the principle of, allowing return traffic to proceed if ingress traffic is allowed in. In case no match is found in the reverse sk_lookup, traffic falls back to the regular egress path.
This reverse lookup is only performed in case an sk_lookup ebpf program is attached and the source address and/or port for the return traffic have been modified using the (newly added) IP_ORIGDSTADDR in sendmsg.
Is it compatible with SO_REUSEPORT ?
Most heavy duty UDP servers use SO_REUSEPORT to spread incoming packets to multiple sockets.
How is the reverse lookup going to choose the 'right' socket ?