Make your own VPN with Fly.io, tailscale and GitHub
github.com
github.com
If someone's interested, this blog was very helpful: https://www.procustodibus.com/tags/wireguard/
The tailscale daemon/CLI/client code is already open source and works with the above as the control server.
The tailscale team appear to be encouraging development of headscale too:
"Our opinion is that Headscale provides a valuable complement to Tailscale: It helps personal users better understand both how Tailscale works and how to run a coordination server at home. As such, Tailscale works with Headscale maintainers when making changes to Tailscale clients that might affect how the Headscale coordination server works, to ensure ongoing compatibility."
> https://tailscale.com/opensource/
Personally I find WireGuard and tailscale/headscale to be extremely complementary, and with these you don't cede any control vs running WireGuard on its own.
Besides, Wireguard alone already does all I need from a mesh VPN. The UX could be a bit better, but I wouldn't trade ease of use for the peace of mind that my VPN traffic is secure.
Though doing this "well" is subjective, so I can understand someone preferring Tailscale because it's easier to use.
if your access concentrator (server) is behind a nat, you'll need a port-forwarding from the outside but that's rare.
For example, you can set ACL rules for which devices can access which others (or the internet, if you have explicit exit nodes) - it's using Wireguard for networking, but you can't do that with (just) Wireguard, it's not just 'make Wireguard easier to set up', as you said that doesn't really need doing.
There's value to some to having networking config centralised like that. It allows things like auto adding certain clients to certain rules/groups automatically.
Not spending time cycling through each server to poke iptables.
This is just irrational. The client is open source. You can build it and run it from source.
The sentence following the one about phoning home/leaking data explains the rationale. The computer user prefers simpler software. It's great that it's possible to compile a client provided by Tailscale from source, but this does not address the complexity issue.^1
Is the Tailscale control server open source. Why not. What's the rationale for that.
There's no problem IMHO with arguing Tailscale can make its own decisions and do whatever it wants. However the same argument must apply to the computer user. He can make his own decisions and do whatever he wants.
1. Wireguard was allegedly written at least in part because OpenVPN, another open source option, was excessively complex. Tailscale relies on Wireguard. If avoiding complexity was irrational, and people behaved rationally, then perhaps Wireguard would not have been written and Tailscale would not exist.
Avoiding complexity where possible sounds rational to me.
The official reason for why there's no official open source server is that headscale got there first, before tailscale team could (their words, not mine) the unholy mess that was the production server into something people could compile and deploy themselves.
Even so, software being open source doesn't make it inherently trustworthy. I would have to look into it, or trust that the community has done due diligence. My default stance towards all software is to not trust it, which can change as I get familiar with the project.
And then there's the complexity. I prefer using simpler tools if they accomplish what I need. It's less surface area for me to trust, and less chances for bugs. Not that Wireguard is necessarily simple, but since Tailscale is a wrapper around it with additional features, none of which I need, I'm perfectly fine using WG directly.
Something I don’t understand is if the client is open source, why is it not in the fedora repos? Why do I need to add a new repo to dnf?
Just because one group of people haven't done something doesn't mean it doesn't qualify. To show the exact opposite, look at OpenBSD. They have included Wireguard into their kernel.
Fedora not including Wireguard may be political, personal, or none-of-the-above. Maybe somebody hasn't offered to take on that task/responsibility.
The master config is essentially the Fabric script. It contains each servers IP, public key, etc. We even do server-server pre-shared keys.
I tried installing headscale. I didn't feel like I got the immediate rush of "cool, I have the baseline thing working" without reading the docs. And, I needed to use this for a GUI: https://github.com/gurucomputing/headscale-ui. I love the command line and am happy to use that, but I'm unsure if there is a benefit to headscale over wireguard if I'm already doing command line management.
I just read this article on tailscale vs. openziti and it mentioned netmaker (a YC company). I tried installing it, but out of the box, the "DNS" did not seem to work correctly (I could not use the machine.netmaker local alias, and not sure why not).
Is anyone here a power user that also benefits from a full fledged GUI? Is tailscale the only option there? I prefer to self-host whenever I can, despite loving tailscale and the people behind it.
But one thing that Tailscale didn't do well (at least early on) is performance. It's user space Go, which seemed to cap the data transfers when I tested it out. I would prefer a really fast data transfer P2P so I could use Tailscale in between my web server and DB.
Compared to another VPN? I’d be curious to know whether the kernel mode byte shuffling solves that problem. But even so, a kernel module is a pretty big ask only for connectivity.
In my experience, UDP in general isn’t as performant in practice as one would think. Not saying you can’t push the limits, and even outperform TCP, but to do so with a reliable cross platform way isn’t exactly trivial today.
All my benchmarks (albeit user space) have shown that pushing bytes over udp has a higher CPU overhead, and that’s even if you omit retransmission, congestion control, etc etc (ie just push garbage bytes). And even if your cpu can handle the throughput, the congestion control can still bite you for god knows what reason. When I ran quic benchmarks they got deprioritized in the presence of tcp traffic. Don’t know all the reasons why (sorry, just didn’t have the time) but at least to me TCP wins the bang-for-the-buck-throughput-on-commodity-hardware category, hands down. Maybe this changes with platform-specific optimized vectored IO, but that alone would be a huge effort. No, the more time I spent on it, the more I appreciated all the things TCP gives me for free, and it’s remarkable resilience in complex conditions. I am also happy I don’t have to worry about bulky 3p libraries. This is what the OS is supposed to do, imo. So this UDP-hype-renaissance we’ve seen over the last years is a bit premature or at least not as obvious as people hoped (including myself).
Another fun fact (for anyone who read this far): contrary to popular belief p2p TCP isn’t harder to do than UDP, not really.
Another thing I wondered about is how much CPU overhead VPNs add, and how it performs when maximizing throughput. (Not Tailscale but a “regular” one with kernel packet switching). Do you have any experience with that?
> VPNs that use TCP as the transport layer could try and special case TCP handling and treat them as a flow and just transport the TCP data streams instead
Yes! An interesting observation is that TCP composes really well, ie relaying works excellent. However, for VPNs it’d be nesting TCP which melts down quickly.
To be clear, nothing specific to Tailscale right? Just generic prudence?
There is a third-party OSS server they let the official client work with. Similar to Bitwarden/Vaultwarden.
I don't usually do admin stuff nor I unfortunately know much about network setups nor I know about the specifics of tailscale setup.
I tried the open source tailscale alternative netmaker which is quite nice but in the end I found it unnecessary for my 5-6 hosts since the wireguard stuff for me is basically set-it-and-forget-it. (I chose netmaker because it also uses wireguard.)
If you always go to your own vps then that IP address is tied to you, typically via a credit card.
use those to pay for VPNs, like PIA or Mullvad.
until docker info > /dev/null 2>&1; do echo ”docker isn’t running…” && sleep 2; done
should have probably let you find this out for your self.
until indeed seems like syntax sugar for while !, I don't think there's a difference.
This is not the case. From the Open Group Base Specifications Issue 7, 2018 edition, 2.9.4 Compound Commands, The until loop:
The format of the until loop is as follows:
until compound-list-1
do
compound-list-2
done
The compound-list-1 shall be executed, and if it has a zero exit status, the until command completes. Otherwise, the compound-list-2 shall be executed, and the process repeats.The downside is that my traffic never went direct; it was always relayed via a Tailscale DERP node, as Fly.io machines were only accessible via anycast, and so a direct connection from Tailscale on my machine to the exit node on Fly.io couldn't be established.
So performance wasn't as great (and I felt bad about using up Tailscale's DERP bandwidth, as a free user).
Possibly you'd have more luck on a network where your client can allow incoming UDP connections on the Tailscale port, and so the exit node would be able to establish a direct connection.
But for a Tailscale peer I have running on AWS ECS, I can open the UDP port there, so a direct connection always happens regardless of what sort of network my Tailscale clients are on. I don't know if there's any Fly equivalent to get a direct connection to a UDP port.
I just tested it again and the connections are made directly (after the first 2,3 packages go via DERP):
tailscale ping fly-ams
pong from fly-ams (100.96.123.32) via DERP(ams) in 15ms
pong from fly-ams (100.96.123.32) via [2604:1380:4601:d605:0:6c3b:eed5:1]:41641 in 12ms
tailscale status
100.96.123.32 fly-ams patte@ linux active; offers exit node; direct [2604:1380:4601:d605:0:6c3b:eed5:1]:41641
100.101.54.36 fly-hkg patte@ linux active; offers exit node; direct [2605:4c40:95:4eed:0:40f0:67b1:1]:41641
Fly.io or not, this was an issue I always ran into with Tailscale.
They talk a big game about NAT punching, and using various UDP shenanigans to get around P2P connection formation issues, but at the end of the day, most of my connections were via DERP, even with fairly trivial firewall configurations.
This is why TLS exists. Just set up DNS over HTTPS and you'll be fine :)
It's hilarious to me that DO doesn't trust DO servers (and their customers).
Note: Asian region does not offer the full 160GB, but only 20GB IIRC, like HKG and NRT.
This way you don't depend on a VPN provider, and can easily host it on any VPS. I suppose it would work on fly.io as well.
I use the hub and spoke setup to access my home network over the internet, and Wireguard works great.
This also doesn't require any special gateways or DNS setup. All connected hosts just use the DNS server on my main router, which resolves all internal domains.
Which works horribly on 464xlat providers, as now you're routing your VPN traffic over a IPv6->IPv4 proxy. While that's fine for outgoing stuff it breaks all incoming stuff as soon as you put your phone to sleep, as nothing can send stuff your way anymore.
I don't use IPv6, so this hasn't been an issue for me. It sounds like a relatively simple thing to fix, though.
OP, why not use an open source equivalent to Tailscale Funnel? For example, I work on the OpenZiti project and we created zrok.io which is fully open source alternative - https://github.com/openziti/zrok.
They also have caddy-tailscale which directly connects a tailnet IP with Caddy as a proxy. The development has stalled as it seems, but works.
[1] https://blog.scottgerring.com/automating-tailscale-exit-node...
You sometimes get lucky and get something that doesn't resolve to United States, and sometimes the IPv4 is US, while IPv6 is correctly the location, or vice versa.
Fly.io is aware of it but not something that's resolved.
https://community.fly.io/t/regional-ips-dont-seem-to-be-in-t...
> Geo IP databases are very inaccurate for companies like ours. Some of our IPs are registered with RIPE 3, and thus default to Amsterdam. The geo IP providers might choose to use our corporate address for those instead, but then they’ll show in either Chicago or Delaware.
> Meanwhile, we can put IPs anywhere in the world with a one line config change. We won’t, but the IAD IPs could just as easily be routing to Sydney tomorrow. We could even route it everywhere!
> traceroute and mtr are the only real way to see where a given connection is being routed. You can usually see city names and airport codes in the intermediate hops.
> IP databases don’t actually try to solve this, they’re mostly interested in identifying consumer locations. The ISP’s business address is often good enough for consumer IPs.
[0] https://ipinfo.io/blog/probe-network-how-we-make-sure-our-da...
More and more I'm just thinking stuff like what Signal did with a proxy server makes sense. Run a bunch of proxies, hide the complexity. Maybe default it in the browser. Maybe I'm old, who knows.
Also not clear where its located
Outline is part of Jigsaw, which is a part of Google. Is it truly private?[0][1]
[0]: https://getoutline.org/faq/ under the "Outline Brand" section
[1]: https://github.com/Jigsaw-Code/?q=outline Jigsaw's Github with the Google affiliation.
Tailscale is cool for sure but it also requires a third party involved in this. Outline has no third party server component. For almost everyone Outline is much easier to setup and use.
> so no sharing if config or keys. just invite them to your tailnet of share the server to their tailnet.
It's the same level of effort as outline. Outline manager has a button that generates an invite that someone else just puts into the outline client and now they have access to your VPN. You can revoke keys and do all the things you'd expect to be able to do, but again with no third party involved.
Plus, from time to time, I will contribute back. Making sure upstream still works.
In order to easily watch region-restricted content, I want to put all entertainment devices in my house on a separate wifi router, and run all traffic through a chosen tailscale exit node.
So you could do exactly as you planned, just with the router -> exit node (or router -> some Tailscale relay as an extra step to provide that interface) as plain Wireguard.
If all you need is to "change your IP" for some specific purpose, this and many other tutorials out there can accomplish this task for <$5/month. You are in complete control and have to trust no-one. However be aware of the following downsides:
1. You are mapping your traffic 1:1 to the VPN IP address, that you are the sole user of. This will do virtually nothing for pseudo-anonymity as your original ISP assigned IP will be quickly linked to your new VPN IP by every single shady data broker out there as you lose the benefit of "being lost in the crowd" when you share VPN exit IPs with hundreds/thousands of other people.
2. If you do anything shady that results in a LE subpoena or a DMCA, it's like you were not using a VPN at all. The cloud provider will hand over your details instantly.
3. Many sites block data-center ranges. You will not be able to use most streaming services, and random websites like Papa Johns, Home Depot, banks, gov websites, Ticketmaster, etc. Not all ASNs are banned, but many are. Commercial VPNs can (and do) re-route traffic using "residential looking" or actual residential IP addresses to combat this.
4. Performance MAY not be great. VPN providers do quite a bit of Linux kernel tuning in order to get high(er) throughput.
Depending on your use case, the above may not matter but if you plan to use this 24/7, be prepared to be annoyed.
On a commercial side, we take reports from users. If someone tells us bank X doesn't work from VPN country location Y, we can fix that in minutes.
But using your ControlD service, OP can get it for $0/month, right?
Also, Control D is a DNS service, not a VPN.
Just be mindful that despite it being able to spoof your location, SNI is still in the clear. https://en.wikipedia.org/wiki/Server_Name_Indication
Are you aware of anyone actually offering this service? If so, hit me up, my email address is in my profile.
I mean, you have to trust the VPN for reasons you enumerate in (1):
> This will do virtually nothing for pseudo-anonymity as your original ISP assigned IP will be quickly linked to your new VPN IP by every single shady data broker out there as you lose the benefit of "being lost in the crowd" when you share VPN exit IPs with hundreds/thousands of other people.
Besides, post Snowden, it is silly to still believe in such claims as non-logging. there are many high probability possibilities:
– it is a legitimate business but a secret court order compelled it to install a tap and feed it to secret government agency.
- its not a real business but actually a secret govt security agency's slush fund funded cyber intelligence warfare operation.
- its an unscrupulous mafia funded business running a massive hacking/blackmail operation masquerading as a business.
- its an unscrupulous shady business that's harvesting and selling your personal data to black market data brokers.
...so on. possibilities are endless.
Shady businesses are out of scope when it comes to laws, but that's true for any industry. There are ways to protect yourself, if your opsec warrants it, by "double wrapping" and using 2 separate VPN providers simultaneously.
Greed is also a huge factor. Dishonest providers can implement all kinds of SDKs into their software and 2-3x their revenues. This is why its important to use VPNs that offer open source apps you can audit and compile yourself which would protect against some obvious violations, but one can do all kinds of evil shit server side without the end user ever knowing.