Le ven. 20 sept. 2024 à 19:03, Tiago Lam <tiagolam@xxxxxxxxxxxxxx> 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 ?
