The Technical Challenges of Building Cloudflare Warp
blog.cloudflare.com
blog.cloudflare.com
However, I had to previously uninstall 1.1.1.1 after I found it draining my battery. I had a few mysterious instances of my phone dying a day early, and I couldn't figure it out until I found it warm one day and dug into what was using the CPU while idle. Turns out it was 1.1.1.1. I uninstalled it and the problem went away. I very much hope that's been identified and fixed by now (I use Android on a Pixel One.)
Re: NAT and source port changes
I am experimenting building a similar tech but on AWS. To use anycast, I front my Wireguard servers in multiple regions with GlobalLoadAccelerator and set ClientAffinty to two-tuple (source-ip, destination-ip) instead of the default 5-tuple (source-ip and port, destination-ip and port, protocol).
Re: Network switch (WiFi to Cellular and Mobile IP)
This one stings. I haven't impl it yet, if ever I get to the scale to warrant such a design: I was thinking abt sticky routing the traffic using only the destination port (of the wireguard server). At the time of new connection establishment (VPN turned on / off), ask the app server for a port to use and use that. On the server end, have one beefy wireguard server serving a range of ports per region behind the anycast load balancer, so that the balancer has no choice but to send the incoming to that single server that is serving incoming destination port. Use the usual IP route commands to send the traffic along to approp exit server depending on the actual destination IP (now that wireguard has decrypted the packet).
Re: Clients:
I'm predominantly focusing on Android, and the I've found things work differently across OEMs. It is just too much work. I have gone with the workaround that Blokada so wonderfully uses: employing a watchdog, heartbeat, keep-alive service, and aggressive wake-ups for some of the common problems across OEMs.
[0] Google's paper on NetworkLoadBalancer is simply amazing: https://ai.google/research/pubs/pub44824/
[1] https://ai.googleblog.com/2015/08/pulling-back-curtain-on-go...
> After considering and testing several more modern options, we landed on WireGuard®. WireGuard is a modern, high performance, and most importantly, simple, protocol created by Jason Donenfeld to solve the same problem. Its original code-base is less than 1% the size of a popular IPsec implementation, making it easy for us to understand and secure. We chose Rust as the language most likely to give us the performance and safety we needed and implemented WireGuard while optimizing the code heavily to run quickly on the platforms we were targeting. Then we open sourced the project.
> [argo continually monitors] thousands of routes over the Internet between our data centers. That data builds a database which maps every IP address range with the fastest possible route to every destination.
and then they seem to assert that this is impossible with https traffic because the tcp payload is encrypted. For routing, as I understand it, none of the payload should have to be inspected... what am I missing?
What they're saying is that Warp+ will send the packet across their private network rather than sending just on the plain internet.
For example:
You're in Italy. You want to send a packet to a server in New York.
On the internet the path is unpredictable. Because there's a lot of hops from different networks etc.
Cloudfare are saying that your packet will enter their Italy PoP. (they may have more on the country I don't know)
Then via their separate private network, it will travel to the New York PoP.
Then out to the internet to the destination.