Tailscale Funnel
tailscale.com
tailscale.com
Usually people are pretty critical/cynical of sending sensitive data to a closed source third party server, no matter how strong their claims of 'being the good guys' are (eg see Telegram).
But somehow we're all meant to be happy giving full control of our entire network to a commercial company running a closed source command and control server?
Their MagicDNS feature may raise different concerns though, but I'll let others comment on it.
TFA mentions that the immutable certificate logs reveal if something spooky is going on. Not enough of a guarantee since the tailscale client may siphon off certs from a local device to its servers anyway. But that's us being extremely paranoid about tailscale (in which case, why use it?).
Second, most services are run behind reverse-proxying load balancers which invariably are setup to "MiTM" aka terminate TLS. The providers running those load balancers control IPs + DNS records too, for good measure.
I guess, supporting a dizzying array of functionality makes Tailscale a decentralised cloud service provider themselves.
For some weird reason the GUI clients for Windows, macOS and iOS are closed-source.
I never understood exactly why that is, considering that the Linux and Android ones are fully open.
The fact that there isn't a reason documented anywhere certainly worries me.
EDIT: I saw another comment that says that it's "just" the GUI applications for Windows and Mac that aren't open, but the core functionality is. I know that in Windows-land, it's _very_ common to use proprietary UI libraries like Telerik UI[0], or devexpress [1]
[0] https://www.telerik.com/purchase/individual/winforms.aspx
https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
I do that mostly because it's running as a LaunchDaemon.
> Forget the server
Pop the headscale server in and you get a fully FOSS system.
https://github.com/juanfont/headscale
That I don't do, because the coordination server, the relay system (which you can also self-host), and the server side UI are really good.
And also the public behaviour of the persons working at Tailscale as well as Tailscale's approach towards FOSS generally increase my level of trust in them. IOW they strike me as Nice Folks(TM), and if Nice Folks(TM) don't inspire confidence to you then you probably want to run the whole thing as described above.
I mean, please read this in its entirety. They even have a "Encouraging Headscale" section.
Honestly that makes it even weirder.
Usually companies will just not acknowledge that an open alternative that plugs into their existing product exists, and if they do it's for enforcement/diverting purposes ("Don't use this, please stick to the official stuff")
If you're at a point where you acknowledge, accept, and even help the unofficial FOSS alternative, why not make your official stuff the same way?
In fact, I do this anyway because their Windows client’s subnet router functionality is documented as being less performant than their FOSS client. I use my home desktop running Windows as a subnet router from tailscale into my home network, but when I read the note about performance I quickly installed Alpine Linux on a Hyper-V virtual machine and installed tailscale on there.
That simple Alpine VM takes up so little resources that I don’t even notice any impact on performance with my 2009 12 core Xeon system. (This was a huge system, but I would imagine a modern low-midrange CPU would easily outperform it and likewise handle a micro-VM just as well)
One static route added to my home router, and traffic flows both directions just fine. No need to install the client on any more machines on my network. This also saves on licensing, helping me stay within my free plan. :)
In my mind wireguard was still the new kid on the block.
Technology moves so fast.
Tailscale (or Headscale for that matter if you host it yourself) is magical in comparison.
Add the fact that it has no advantage over nebula and I stopped using it in a heartbeat.
Just use wireguard. It really isn't that hard.
The thing is, what makes tailscale works really well as a "central" control server is that it makes a lot easier to connect your personal machines. You don't need to deploy your own server, or mess with networking stuff. You just download it, log-in and there you go. I myself have invited some non-tech friends to my network for playing lan games from time time and they find pretty easy to setup tailscale on their side.
What may theoretically happen is that the same client won't be able to join both an open-source controller and a controller from Tailscale-turned-evil.
I suppose that corporations, especially those without huge IT departments, will and do happily pay Tailscale the reasonable money, and have their secure VPN just working. For them, it's no different than paying for Zoom or Office365, only cheaper. They totally do not want to depend on in-house networking expertise.
So I think Tailscale will be doing well financially,
Further, Honestly at this point I would trust TailScale over say OpenVPN, or Cisco, or .....
- locking the software behind a paywall
- locking the software behind a paywall
- inventing a proprietary + open-source + pay us royalties license
- pretending that their software is free whilst employing a proprietary + pay us royalties for anything bigger than a hobby project license
- going bust
For us. For the folks who browse HN all day, yeah. But have you tried getting a non-technologist to use it? I set a friend up with Tailscale between her Synology and laptop and it was a breeze - something I could do over the phone. For me getting Wireguard set up wasn't tricky, but I definitely leaned on Google some, and I would argue I know what I'm doing.
I would love for a company to release bridge as open source that I could deploy on a VM somewhere but still have it be Tailscale easy for normal folks, but there's no money in that model.
In many situations it's not just hard, it's outright impossible.
For example, how would you connect two Raspberry Pis between two CG-NATted internet connections using Wireguard, without resorting to setting up a publicly reachable VPN server?
If you have a public and at least semi-stable IPv4 address and control your firewall/NAT, great. But unfortunately less and less people do, these days.
Have you tried using IPv6 on a hotel wi-fi, in-flight, or a corporate guest network?
TLDR; Ideally, IPv6. Otherwise, NAT traversal techniques such as STUN, or hole-punching.
Yes, if you have it everywhere you want to host services and everywhere you want to access these services, that's great. Realistically, I think it's going to be decades until an IPv6-only service is feasible.
> Otherwise, NAT traversal techniques such as STUN, or hole-punching.
Neither of which Wireguard supports out of the box. To be clear, it absolutely shouldn't – it's a different concern, and the appeal of Wireguard is specifically that it isn't trying to do everything and the kitchen sink.
So, is there an easy-to-use NAT traversal orchestration service for Wireguard out there that isn't Tailscale?
So, before Tailscale there wasn't a solution. Now we have one, but it's yet another tool we have to manually manage.
Road 1: Sale to usual suspects like Palo Alto (though that window is closing due to raising $100M) or Cisco (that window may close if they raise again?). It is basically modern vpn, though will be years with a big enterprise culture reset & a consumer tier for that to become true. They will run out of acquirers soon who would have the incentive to overpay, eg, if they raise more and narrows down to say oracle, ms, apple, and google, not sure why any would buy vs build. Hopefully they will not dip much into the funds so they can cleanly exit without forcing an acquirer to screw over their users. (See: Evernote)
Road 2: IPO and become a platform for bigger stuff... Like end-user-friendly VPN. Who knows, but good luck! Flipping to 'real' enterprise sales and figuring out the consumer tiers are big culture shifts, but luckily... Hireable.
Meanwhile, growing just with more niche/skilled Linux power user teams gets them far -- the compliance checkbox is huge for growth, see Drata and Vanta -- so am not worried :)
Agreed with the OSS concern so we decided against putting them in the critical path of our enterprise offering (a shame!), but as an internal tool, it looks great!
I love WG and use it extensively, but the attraction of Tailscale (and why I use it) is that it takes disparate concepts and gives you a nice visual control panel to manage them and see the status of all your devices in one place.
Nothing. Absolutely nothing exists for Wireguard that does even some of that, which doesn't also cost money.
I don't think Wireguard is even capable of the 'DERP' server concept to get around NAT limitations.
So no, you can't 'just use Wireguard' to accomplish what Tailscale does.
I can't (and refuse) to live my lie by "what ifs." If they do any of those things, it's easy enough to pivot to the 3 or 4 other providers our there, like ZeroTier, who offer the same thing.
My hope is if they do, the FOSS community will have gotten their act together and built a capable replacement, which is usually the case.
Yes, Tailscale is THAT good this tradeoff is worth it.
NAT is a godsend for IPv4 exhaustion, but it's also fundamentally crippled the ability for people to host things or make things available directly from their homes.
Hole-punching is an inexact process due to the variety of different NAT types, some of which (e.g. Carrier-grade) simply do not allow that sort of connection. So there must be a middle man that accepts packets on their publicly available port and passes it on to another established connection. TURN/STUN (et. al.) exist but are archaic and do the same thing but with less accountability.
I hate it too but until we have IPv6 by default with user controlled firewalls hosting something in your garage without a business line is not feasible. Hell I have a 5$ a month VPS purely so it can act as the middle man to the servers in my home. At least then I only need to trust myself as the middle man.
The problem is their control plane that controls the encryption keys. A malicious admin inside TS (or a hack) could grant itself membership in any of their customer's networks. (Or at least this is the worry I read from GP)
Aside from that, it's definitely a problem that they could include themselves in any customer network, but the accountability still stands. If someone got in without your screw-up, at least you know who to point the finger at once the dust settles.
I'd argue it should be treated as a base to overlay your network on top of. Although admittedly I say that as someone that doesn't use their services for similar reasons.
How do you know you didn't screw up? There are so many vulnerabilities in the gazillion or random stuff you run every day on your laptop. I'd argue it's more likely that something like that was breached than Tailscaled was breached or rogue.
They enable you to move your selfhosted services from expensive, slow VPSes you don't control to fast devices in your own home[4]. IMO this is strictly better than a VPS in terms of privacy and data control. It's a step in the right direction, back towards the initial intent of the internet, but also forward with the lessons we've learned in the real world.
The reality today is that selfhosting is way too hard[1]. It shouldn't be any more complicated or less secure than running an app on your phone.
I think services like Tailscale are going to enable the first generation of selfhosting that approaches that level of simplicity. Once the market is proven, the second generation is going be designed for selfhosters and have features like end-to-end encryption, domain name integration, and simple GUI interfaces.
The other key pieces are strong sandboxing, which is now possible on all major desktop OSes through virtualization (mobile is coming[2]), and dead-simple cloud backups.
The technology for all these things exists, it just hasn't been integrated yet.
[0]: https://github.com/anderspitman/awesome-tunneling
[1]: https://moxie.org/2022/01/07/web3-first-impressions.html
[2]: https://twitter.com/kdrag0n/status/1584017653269958656?lang=...
[4]: I concede that the network upload connection is likely much slower, but expect that to improve over time.
I want to teach something like Tailscale about my contacts, so they are allowed to communicate with my services (through their services).
Then I want to run an app inside a strong sanbox that has capability-based APIs to do things kind of like ZeroMQ for sending messages TO THE CONTACTS. I don't want the API to look like a tcp/ip or udp connection. I want the app to think it's sending a message to a contact I've given it permission to talk to.
If this was running in a strong sandbox, I think this would be an awesome way to develop and use simple federated apps. If something like Mastodon existed on top of this, I'd think it would be really secure and much easier to tell people to stand up their own node...
But if I were really bought in to Sandstorm.io, developing new apps for it would make a lot of sense, and I agree with their assessments about accounts and security - that those are better left to the OS.
So I'm just wanting to build federated apps, using that same philosophy.
And if Tailscale Funnel let me safely run in a sandbox on prem...?
That sounds amazing.
Like, this is the kind of thing where I'd buy a headless PC just to host federated apps for my extended friends and family network, if the config were painless enough and the sandbox secure enough, and the self-updating, self-maintaining story of Sandstorm.io worked well enough...
It's like the Chrome OS of federation, in my head. The OS does exactly and only what you need, making it easy for you to add the business logic of your thing.
Like, I wish this was roughly how SAS worked...
I wish to hell more businesses felt secure in letting their employees stand up convenience servers. And I feel like these are steps in the right direction.
How is trusting your network entry point to Cloudflare (or whoever) any better than having it at a VPS? At least with the VPS you know what's happening inside the box.
Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
I was referring to the other advantages, not the privacy. They're about the same on privacy.
> Here's a better solution: Get a free/cheap VPS. Setup a Wireguard tunnel from your home server to it. Slap a reverse proxy on the VPS that forwards internet traffic through the tunnel to your home server.
Way too difficult for the users I'm trying to reach.
Try this: Go set up a Wireguard connection from your PC at home to one at work.
Then do the same thing with tailscale.
One will be a lot easier than the other. And that's only 2 computers...
WG is the easiest VPN I've ever used. Dropped all these other crazy rigs (stunnel, ssh-tunnel, etc) cause WG always "just works" and is on every platform.
However, I've spent loads of time as network admin, planning IP-space for VPN layers, first time in 1997.
That says a lot, to me at least, but parent's comment on giving the keys to the kingdom to a third party still holds (as it does for many other SaaS/cloud/hosted platforms of course).
As far as I can tell, the Tailscale magic is maintaining and distributing a wg.conf that is setup for a dynamic mesh Wireguard network. To do this (and in particular the NAT traversal aspect), they use their own software to setup and figure out NAT ports.
One you have Wireguard figured out, it’s pretty easy to setup a hub and spoke model VPN, especially if you have a static server somewhere. Setting up a dynamic mesh VPN is another thing entirely and doing it without requiring a server from Tailscale to be part of the network is, like I said, a bit of magic. It’s a straightforward setup that they explain quite well on their site. But to actually make it work is quite impressive to me.
AFAICT, Tailscale does not route your traffic through its servers (because it would be costly, among other things), but it does control your VPN nodes to distribute all the configuration fairy dust. So a server from Tailscale is still needed (and billed for).
Except of course in the case of Funnel... which is the original subject here. In this case, the Tailscale ingress server is added to your private network/nodelist. This it so that it can communicate with whatever private service you are running and then proxy that back out to the public Internet.
The big question is going to be pricing. The current top player in this space is Cloudflare Tunnel, which is a loss-leader product that technically forbids selfhosting anything other than HTML sites.
Selfhosting media can use tons of bandwidth. Any service that doesn't charge per GB is incentivized to limit your speeds.
It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
BTW this maintains data privacy but you can still tell a whole whole lot from metadata.
On the flip side it would prevent the kind of “griefing” with DDOS that happens every once in a while with self hosted and P2P things. It’s not that common unless you are engaging with certain communities but it is an inherent Internet architectural flaw that this kind of works around (at a cost).
> It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
I just don't see ISPs ever implementing IPv6 without governments forcing them to. It enables p2p which increases upload bandwidth requirements and cuts into their bottom line. And even if we get IPv6 you still need the ability to open firewall ports in a way the average user can understand. Not hard technically but that's another standard that everyone is going to have to agree on and implement.
[0]: Which I know you can appreciate. "Decentralize until it hurts; centralize until it works" is still one of my mottoes.
PS - typing the IPv6 address was super annoying and error prone compared to IPv4.
Depends on the carrier network though. I am on Spectrum (Verizon network) in Ohio and get V6 with CGN for V4. My wired ISP provides dual stack.
You still usually need hole punching with IPv6 if there's any kind of firewall in the way, but unlike IPv4 with NAT it's virtually 100% successful. Even if IPv6 NAT is deployed there's usually a 1:1 internal/external IP mapping making hole punching 100% successful.
It works better outbound than the old model though. I use iSH to get a Linux shell and with a mini Bluetooth keyboard I work on some hobby projects on the train from my iPhone.
The hard truth is that implementing IPv6 costs money and customers are not willing to pay for it.
Once you wire fiber upstream bandwidth doesn't matter that much. ISPs are directly peered into the core of the Internet and pay bulk peering bandwidth pricing not cloud bandwidth pricing. Cloud bandwidth pricing is completely insane, like 10000% markup or more in many cases, and the fact that they charge more for outbound is just a strategy to make data flow into their cloud but not out. Bandwidth is actually dirt cheap or companies like Cloudflare could never exist.
The main reason they drag their feet on IPv6 is that there's no strong forcing function and dual stack adds complexity. When they're on a deadline to ship they punt on it. They are starting to get complaints from gamers though. Gamers tend to be the top home users that drive early adoption of all kinds of things.
Edit: another funny thing is that most ISP/telecom stuff these days is IPv6 at the core. If they're not doing it at the edge for new stuff it means they've just got it off and are running IPv4 over IPv6 within their network most of the time. This is even more true for mobile networks, some of which are IPv6 only and the phone does 4to6.
The rollout is still happening... slloooooooowly... The Internet is huge and it takes forever to do a major upgrade like this. I wish they'd have just made IP 48 or 64 bit with an easier upgrade path, but that's water under the bridge now.
Overlay networks are probably the future. IPv6 lets them be fully P2P and more decentralized.
Edit: one more piece of detail about upstream bandwidth at home. 30-40mbps/sec up is a DOCSIS cable system limit. That's the only reason for that really. Cable was never designed to be bidirectional and the stuff they do with modulation to get shared upstream is heroic. It's also related to why cablemodems tend to use a lot of power. They have to blast spread spectrum pretty loud to get it to the CO. Fiber will save energy.
That is awfully expensive for something ipv6 already solves minus the privacy part. I don't see how it can be considered "huge". A slight convenience maybe?
Also, routing everything through a 3rd party is a massive downside.
Here’s the attack:
- You want to get to A
- And you’re on a device B that has access to hole-punch-as-a-service but no direct access to A. Good network administrator / sysadmin!
- Attack NDP (ie ARP spoofing but IPv6 flavored) to trick the firewall just for a moment that you’re A [1] and request the port be opened to your evil server C on the public internet.
- Oops.
EDIT: I agree we definitely need something like UPnP, or maybe even UPnP itself, but it's another adoption problem currently.
AFAIK it doesn't use third party servers and it seems to get through any router just fine...
This can have quite an effect on sync speed. I set it up for my dad and initially his PC and laptop were syncing incredibly slowly. It turned out they both thought his home network was a public one, so everything was going out to a relay server and back.
This explains so much of what I’ve seen added to their codebase recently
Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.
> Our connector, cloudflared, was designed to be lightweight and flexible enough to be effectively deployed on Raspberry Pi, your laptop or a server running your data center. Tunnel does not programmatically enforce any throughput limitations.
> If you are hosting a Tunnel in GCP, AWS, or Azure you can view our deployment guides which are more prescriptive in assigning minimum system requirements.
https://developers.cloudflare.com/cloudflare-one/connections...
I'm eager to get rid of needing DDNS and open ports just for web hooks. And I can "flatten" my stack by cutting out a reverse proxy / weird port forwarding stuff.
Just the other day I stumbled on DERP [1] their wireguard-over-tcp (over their node network) implementation which they fall back to if NAT traversal fails. While sure, this is partly ipv4 problem, it recently helped me connect with friends behind government firewalls, presumably because the packets aren't recognized yet.
But that sort of automated connectivity during nat traversal failure through a global network of edges isn't something you can easily setup yourself (if you care).
[1] github.com/tailscale/tailscale/tree/main/derp
IPv6 is an option, but not the one true answer (yet?). It helps sometimes.
For Tailscale, IPv6 helps about 7% of the time to bust a NAT connection.
We race all the options and see which works & is fastest. It's likely it's more like 16% or more (I don't have that number handy) in practice but 7% is just how often it would've not worked at all and had to go to DERP relays if it weren't for IPv6 being an option.
This looks like yet another feature that fits my use case and reduces my security burden. Though learning a few things from this post the first being that I should have replaced my use of haproxy with rinetd ages ago. The other about Certificate Transparency logging. Still going through the wiki pages to understand how that works, but would it really log an event such as Tailscale terminating the request, dumping the data, and re-encrypting them before sending us the request? Or is it possible for a bad actor to hide the logging?
For that they need a certificate. They have two options of obtaining that:
a) They request one from a CA. This will be logged in Certificate Transparency logs, and thus you could detect it by comparing the certs logged with the ones your local machine generated
b) they could have their software upload the certificate from your machine. That would need effort to detect (deeply inspecting the software and/or its traffic), but if a whiff of such a "feature" were to be found by anyone it couldn't really be explained away. (and aren't their clients app open-source? then at least it'd be reduced to source inspection and compiling yourself, which makes hiding stuff harder)
Only for Linux.
(On macOS I think the core CLI part is open source as well, but that's not what most people use I think.)
Most of the Tailscale client’s functionality is implemented as a daemon called tailscaled which is in the OSS repo.
It’s the GUI front ends for Windows, MacOS and iOS that are not.
Re: macOS and the Network Entitlements shenanigans: if I understand correctly, it is possible to just run tailscaled unsigned [1] via /dev/utun instead of Apple's APIs. Would it be possible to get this into the GUI so that if you want, you can compile it from source and don't have to do the Apple dance?
[1]: https://github.com/tailscale/tailscale/wiki/Tailscaled-on-ma...
[1]: https://xbarapp.com/
tailscaled isn't particularly stable on my machine though, so I guess I'll roll back to the closed source version. However, this could be a starting point for a Linux client!
It's a fantastic service but with a big flaw: its iOS app eats battery like crazy. I didn't know about it until I accidentally saw it one day: IIRC, it had consumed 20-25% battery averaged out over 10 days. (I used to keep it running in the background all the time, only to route DNS requests to pihole on a home server.) When I googled, it seems like a known problem on their forums for a long time.
So, beware if you are an iOS user.
I‘d really like to use it, but in this state it’s really unusable for me.
Shame though, cause I was also wanting to use it to funnel DNS. I’ve somewhat given up there. I hope they fix their app.
I’ve decided that Tailscale works perfect for all my computers (e.g., Raspberry Pi, Synology NAS, laptop and VPS), but not for my mobile devices. To mitigate this I use cloudflared on my VPS to route internet traffic over tailscale to any internal services that I often use on my phone.
Cloudflared has good options for securing a tunnel by using MFA methods, for example Google authentication.
For the rare occasion that I need to access something else I can always temporary join the Tailscale network from my phone.
Unfortunately, Wireguard on iOS doesn't work very well with dyndns, as it doesn't re-resolve dns and thus silently loses the connection when public home IPs change.
(Edit; though come to think of it, in practice, if the IP address each host resolved to was unique, it wouldn't really matter very much from a security/privacy standpoint, so I guess it's probably not important...)
I just don't trust my VPN to be managed by a 3rd party like this. I'm willing to pay money even (though I don't have much) for hobby use - but I don't like the possibility of exposing network devices like this. To be honest I'm a bit surprised seemingly everyone else is.
https://github.com/juanfont/headscale
In addition to your points, we over here also have our own reasons for self-hosting everything (for example, to protect ourselves from being cancelled at any moment for being forced into a citizenship you didn't ask for by being born at the wrong place).
Tailscale crew: I know y'all read HN, so I say to you: keep up the good work and innovation!
Having an app that can setup its own completely secure networking no matter where it's run is game changing, as soon as I get into the alpha, the Cloudflare tunnel it's on right now is going down!
Seems to me this would save them the hassle of dealing with the bandwidth.
Any plan?
Self hosting Tailscale will then not be needed, since users don’t need to trust Tailscale anymore.
Even with self-provided PSKs, you're going for an (IMHO) pretty poor trade-off; keys, certificates, etc should be regularly rotated, that's a chore that's best left automated. At that point, why not just set up Wireguard yourself?
If you have legitimate concerns, you should be using Headscale[1] (or even plain Wireguard) from day 1. Otherwise - personally I find the current threat model very reasonable, it's in no way worse than trusting any other VPN provider, and they're keeping a pretty big chunk of their code base open for auditing.
Every time they come out with a new product, I read about it and think "Wow, that's really useful. That would be such a pain for me to roll by hand."
Everything they do was already possible with open source tooling, but they make it accessible. It reminds me of when Dropbox first came out.
Technically is it very different from Cloudflare Tunnels?
Anyone have a way to install the client on a non-rooted box? I couldn't find anything in the docs about the assumption that it requires root or not, other than it being implied by their install steps using system package managers.
I'm writing some stuff using this at the moment, but I also just saw https://github.com/tailscale/golink which does the same thing: a single binary that runs a link shortener that joins itself to your tailnet.
tl;dr: don't run your service on a machine then join that to tailnet, directly bind your service to an in-memory tailnet client
I originally was thinking of it like a network-level VPN but realised if I installed it on everything individually it would give me DNS and HTTPS certs for all the machines in my home lab - that work from anywhere as long as my laptop was connected to Tailscale. That is something I always wanted to do with let's encrypt but never got around to. And now this!
It has really inspired my imagination. I've been running labs teaching 5-15 people k8s and k8s security out of AWS but this means I might be able to just run a bunch of VMs in my home lab all with Tailscale loaded and point people easily at them all. Maybe with code-server (VS code in a browser) on them to give them a browser-based terminal. And that is just one possible usecase...
Thank you Tailscale people - it is such a great product that has exceeded all my expectations!
There are also free options, e.g. ngrok [0] And open source options, e.g. openziti [1]
Doing webhooks and dark webhooks for quite some time. Always good to have more options - what does Funnel do differently than those?
[0] https://blog.ngrok.com/posts/getting-started-with-webhooks [1] https://openziti.io/my-intern-assignment-call-a-dark-webhook...
Also, funny they should mention Github, as they literally just added webhook tunneling to the Github CLI a few days ago.
For example, I get a message to my Mattermost client everytime someone pushes/commits/etc. All those messages are sent to the Mattermost server over a webhook that is configured on an overlay network (in our case, using OpenZiti). There's no firewall rule allowing the traffic to the Mattermost server, it's "dark" to the internet.
I assume there are going to be some egress charges for Funnel. Unlike normal tailscale, Funnel has a high bandwidth component to it for hosting high bandwidth services.
We might do BYODomain later. It was easier to launch with only *.ts.net.
If you're using this for things like webhooks, the URL doesn't matter much.
But BYODomain is something that'd be fun to add.
I am watching it very closely and considering to set it up for my small team.
I'm interested to see the limits they put on this, I dont think its going to be as limitless as Cloudflared.
Don't get why this incredibly niche company is boosted like crazy on HN.
Ever since I started using Tailscale a year or two ago, I haven't had to think much about networking for my self-hosted servers at home. It all _just works_. Tailscale is a great example of software solving a real problem in a user friendly way.
You probably don't want that, though, so vanilla Tailscale would let only you securely access your home assistant server from anywhere, as long as you install the Tailscale VPN app.
You can anyways access Jome Assistant over tailscale without all this.
I think there is even a Tailscale addon for HA.
Or more realistically, if you are in web dev and wanted to show your work on your local machine - say when the CEO wants to 'check in and see how its going', you can just send them a link on slack and they can play with what your developing on.
can't the CEO just use the Tailscale network to access it privately?
I just don't personally see a use case -- if I need someone to access the content, the box it is on is already easy to publicly access. if it's not, the only people who need to see it are on the Tailscale network
edit: I think I'm starting to see it. it's not for long term installations. I just feel like, why not just open the box to the internet at that point.
it makes more sense for the edge case(s) that might address friction with adoption. interim solutions, or temporary connections
edit2: I can also see how this might be useful for people living under an oppressive government
How many CEOs you know gonna install a VPN client on their workstation to see your stuff?
e.g., if you're building an integration with any of the myriad of SaaS tools that fire webhooks, you can test in devlocal and have a URL of whatever.tunnel.com.
There are tools like ngrok and localtunnel that exist to do just this. I'm looking forward to replacing those with TS Funnels.
1. How much traffic cost would you expect to get into your DERP instances when this service will be available globally?
2. How much bandwidth would you prepare just for proxying these nodes into public network?
3. How do you think some users might abuse this service in the future?
> Limitations
> - DNS names are restricted to that of your tailnet’s domain name.
> - The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.
> - Traffic over Funnel is subject to bandwidth limits. They are not currently configurable.
I was thinking this would be cool to run some live video stuff on, but maybe that's too much bandwidth for now :)
ZT is absolutely brilliant, but it lacks polish in a few places, that sometimes turn out to be critical. I could probably do a side-by-side comparison table, and ZT would still win in roughly 50% of the cases, but the places where it's losing are causing tiny bits of friction.
ZT flow rules are approximately just as powerful as TS ACLs, but TS has an integrated editor that does formatting, validation, inserts hints and snippets for you, etc. TS ACLs also have test rules that allow you to create assertions, about what must (or must not) have access to what, increasing my confidence when making bigger changes.
TS allows you to tag assets, making complex ACLs easier to reason about.
TS has MagicDNS; with ZT we had to hack something together using their API and a bit of Terraform, and it needs to be rerun every time a node joins/leaves. I could probably write a tiny custom authoritative DNS resolver that talks to ZT API, but TS has it out of the box.
We've effectively soft-bricked a ZT node behind an NAT during a routine dist-upgrade, because dpkg stopped to ask a question, in between the old ZT client version going down, and the new one coming back up. That costed us having to go on site in person to service the device (luckily just that one, and not the whole fleet - but we should've picked a canary node with secondary means of access, lessons learned).
And to be fair, TS is also far from perfect: it's currently allowing one node to participate in only one tailnet, and switching tailnets requires re-authentication in the web browser. This is incredibly annoying in any BYOD scenario, if you want to have separate personal and work tailnets. ZT is infinitely more flexible here: any device can just join or leave networks at will, and it's up to the network admin to authorize it (once).
The list goes on, I really like both tools but the small differences keep adding up in TS' favor.
I wholeheartedly recommend doing your own benchmarks! Everyone's workload will be slightly different, ultimately you should pick what works best for you.
TS uses WG, so that might save so engineering time as well, and they really focus on creating usable features.
For this particular feature I like my own home rolled solution where I automated the process of spinning up a tiny ec2 server with an nginx proxy to a reverse ssh tunnel that goes back to my local machine. It gets a letsencrypt cert and modifies the route53 dns. All managed with a cli command and config file.
The other benefit is that it is completely unthrottled, which is particularly useful if your debugging some stupidly large react/vue website.
Im working on a feature that will enable basic-auth in front of it also, so at least a password would be required to send traffic to your local machine, if you wanted. Good for the "share your work" sort of scenarios.
tl;dr if you want any-subdomain.your-domain.com -> localhost:port, and you use AWS, try https://github.com/nelsonenzo/tolocal
Unfortunately none of those solutions are self hosted AND automated. They all seem to either use their own ifra, which will be slow & throttled, or require setting up a server and manually editing DNS.
I may try to get my own project added to that list though, so thanks for sharing!
inletsctl - automates a VM with the inlets tunnel server preinstalled, including with HTTPS termination with Let's Encrypt, or pure TCP pass-through
inlets-operator - the same for Kubernetes Load Balancer services
Feel free to take a look at https://inlets.dev/
We talk a lot about the community adoption here in the first half -https://inlets.dev/blog/2022/11/16/service-provider-uplinks....
(I'm the original founder of inlets)
mine is free and as easy as 1,2,3:
npm i -g tolocal
tolocal config -> answer the 3-4 questions about domain, vpc, etc.
tolocal apply. -> tunnel will come up to my own custom domain.
You're already offloading critical parts of your infrastructure anyway.
Ie i can self host most of this, but wouldn't i be hosting it on literally a $5mo VPS with a static IP to work around my homes dynamic IP?
Yes, a good UI is product, and people are prepared to pay for that.
It's less about the UI and more that Tailscale takes care of setting up wireguard connections between every machine that needs them, along with the authentication and access control. All of which ends up with a simple network between your devices that doesn't have to worry about physical location and intervening network infrastructure.