PROXY UDP - Githubissues

msantos / libproxyproto

Proxy protocol v1 and v2 support via an LD_PRELOAD library

ISC License

26 stars 6 forks source link

PROXY UDP #3

Open bAndie91 opened 1 month ago

bAndie91 commented 1 month ago

would it work for UDP?

tested with netcat -u, and it made the client send the PROXY header corretly, but not the server. obviously, because there is no accept() for udp. i started to override recv*() family, but don´t know how coprehensive would it be.

my use-case is to make powerDNS authoritative server know the real source when curveDNS being the frontend for DNS requests and it forwards to powerDNS.

msantos commented 1 month ago

Hi @bAndie91 ! Thanks for opening an issue!

UDP is currently not supported:

https://github.com/msantos/libproxyproto/blob/f86c7ad95987023af19f8d9ee6f369f2d9e2a924/libproxyproto.c#L317

The protocol bytes are 0x12 for UDPv4 and 0x22 for UDPv6.

nc -u works because netcat uses a connected UDP socket. Intercepting sendto(2) and recvfrom(2) should cover most UDP usage.

A PR is welcome, otherwise I will look at adding support!

bAndie91 commented 1 month ago

hi @msantos, thanks picking up the line. if i understand well, need to patch these places:

[ ] read_evt() - PROXYv2 the respective address lengths are the same as for TCP so the structs for TCPv4 (((struct sockaddr_in *)from)->sin_addr.s_addr) and TCPv6 are good for UDP as well. maybe a case fall-through would be enough here?
[ ] read_evt() - PROXYv1 it fills in the same structs, so a pair of strcmp(token, "UDP4") and strcmp(token, "UDP6") would make it?
[ ] implement recvfrom() as first glance, the problem is that it does not know how much is read from the socket. do we need to somehow note whether or not PROXY header is read from the socket?
[ ] implement sendto()

bAndie91 commented 1 month ago

i started to implement it here https://github.com/msantos/libproxyproto/compare/master...bAndie91:libproxyproto:proxy-udp?expand=1 currently it does not seem to intercept recvfrom()…

bAndie91 commented 1 month ago

it reads using recvmsg(). [EDIT] source address is in struct msghdr in msg_name field.

bAndie91 commented 1 month ago

now it seems intercepting recvmsg is not enough, because the program understandably wants to reply to the faked (proxy) address. thinking about maintaining yet an other list of real↔proxy address pairs...