Re: Latest http/3 info
On 5/8/2022 3:16 AM, Willy Tarreau wrote: There's no good solution to this, except by forcing the exact address yourself. The BSD socket API doesn't permit to send UDP packets from a specific source, so the commonly used approach for clients is to bind while sending the first packet, but that doesn't work for a server that faces many clients, as it would restrict the traffic to the first IP used. Thanks for that info. I got it working. I set the wildcard entry in my internal DNS to the VIP, configured a specific name to point to the machine's primary address, and then bound quic directly to the VIP address only. TCP bindings are still 0.0.0.0. Then I changed the port forwarding in my router to point ports 22/tcp, 80/tcp, 443/tcp, and 443/udp to the VIP. Adding documentation about this quirk of UDP sounds like an excellent idea. The doc for QUIC should point the user to the doc for UDP for details. Note that in order for the two haproxy nodes to bind to the virtual address you'll likely have to enable ip_nonlocal_bind, but I guess you already have it. When I had two haproxy instances, I didn't need ip_nonlocal_bind. Probably because I used 0.0.0.0 for all bindings and the VIP didn't exist at the time. The dev version has proven stable enough for my purposes that I eliminated the second instance. If I have a problem with it in the near future, I can roll back to a prior commit and rebuild. Thanks, Shawn
Re: Latest http/3 info
On Sat, May 07, 2022 at 09:11:30AM -0600, Shawn Heisey wrote: > If you look closely at the tcpdump output, you'll notice that when haproxy > replies, it replies from the actual IP address of the machine (.200) rather > than the ucarp VIP (.170) where it received the request. Is this something > that can be fixed? Oh that's an excellent point! I remember having faced that in the past on other services (e.g. DNS). That's why most UDP-based services require that you enforce the exact address on the interface (e.g. 10.2.3.4 instead of 0.0.0.0). There's no good solution to this, except by forcing the exact address yourself. The BSD socket API doesn't permit to send UDP packets from a specific source, so the commonly used approach for clients is to bind while sending the first packet, but that doesn't work for a server that faces many clients, as it would restrict the traffic to the first IP used. Note that in order for the two haproxy nodes to bind to the virtual address you'll likely have to enable ip_nonlocal_bind, but I guess you already have it. I think that for the short term we could forbid binding on 0.0.0.0 but that would annoy most users by complicating config deployments. Thus maybe the best we can do is document this limitation. Thanks for reporting this! Willy
Re: Latest http/3 info
On 5/7/2022 9:11 AM, Shawn Heisey wrote: A couple of days ago I noticed that quictls had made a 3.0.3 version available. I upgraded and then tried to rebuild haproxy (master branch). The compile failed. Don't they know they shouldn't change API in a point release? (It's not even a good idea in a minor release unless there is backward compatibility) Doing a git pull today on both quictls and haproxy before rebuilding has fixed this problem. It looks like the haproxy pull didn't update any quic code, so I'm betting the quictls team didn't mean to break things and have now fixed it. They don't seem to have any actual releases yet, so maybe I shouldn't be expecting stability from them. If you look closely at the tcpdump output, you'll notice that when haproxy replies, it replies from the actual IP address of the machine (.200) rather than the ucarp VIP (.170) where it received the request. Is this something that can be fixed? Is it haproxy or quictls that is handling the udp/443 packets? I think that for tcp/443 it is haproxy handling the tcp connection, and it would be my guess that haproxy also does this for udp/443, but I do not know that for sure. I know that much of TCP is actually handled by the OS, but apps CAN get very involved if they want to. I have not dived into haproxy source to the level required to answer these questions. Thanks, Shawn
Latest http/3 info
A couple of days ago I noticed that quictls had made a 3.0.3 version available. I upgraded and then tried to rebuild haproxy (master branch). The compile failed. Don't they know they shouldn't change API in a point release? (It's not even a good idea in a minor release unless there is backward compatibility) Something interesting. I set up ucarp so haproxy wouldn't go down even if my main server dies. When I have my dd-wrt router forwarding udp 443 to the ucarp VIP, http/3 doesn't work. UDP 443 is getting through: https://paste.elyograg.org/view/8731d4cb If you look closely at the tcpdump output, you'll notice that when haproxy replies, it replies from the actual IP address of the machine (.200) rather than the ucarp VIP (.170) where it received the request. Is this something that can be fixed? If I change the port forwarding in haproxy to send to the main .200 address, the external http/3 check works. Thanks, Shawn
