This looks like an impressive accomplishment, and I'm glad Cloudflare got the idea before Google did, because the latter are very interested in hoovering up every shred of data about me to better target their ads. I'll install 1.1.1.1 and give it a try.<p>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.)
Super interesting [0][1].<p>Re: NAT and source port changes<p>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).<p>Re: Network switch (WiFi to Cellular and Mobile IP)<p>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).<p>Re: Clients:<p>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.<p>[0] Google's paper on NetworkLoadBalancer is simply amazing: <a href="https://ai.google/research/pubs/pub44824/" rel="nofollow">https://ai.google/research/pubs/pub44824/</a><p>[1] <a href="https://ai.googleblog.com/2015/08/pulling-back-curtain-on-googles-network.html?m=1" rel="nofollow">https://ai.googleblog.com/2015/08/pulling-back-curtain-on-go...</a>
I subscribed to WARP+ just to support your work. Keep it up! I see mixed comments on HN about Cloudflare’s increasingly central role, and I get that, but my feeling at this point is still positive.
Wireguard + Rust<p>> 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.
Can someone explain the WARP+ section?
First, it says<p>> [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.<p>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?