Most active commenters
  • lo0dot0(6)
  • supermatt(6)

←back to thread

Tailscale has raised $160M

(tailscale.com)
655 points louis-paul | 13 comments | 08 Apr 25 10:36 UTC | HN request time: 0.02s | source | bottom
Show context
briHass ◴[08 Apr 25 23:45 UTC] No.43627559[source]▶
I'm a fan of TS and have been a paying customer for work infra for almost a year now. It really is well put together and easy to use, but I do run up against some issues/complaints when diving deep that I hope they can work out:

* The pricing tiers and included features by tier penalizes you in frustrating ways. The base plan is a reasonable $6/user/m, but if you want to use ACLs to control anything in a workable way, it jumps 3x to $18/u/m. Better solutions are available for that kind of money, and I shudder to imagine what the next tier ('call us') costs.

* Subnet routing broke on Ubuntu (maybe other distros) recently, and there were no alerts, communication from TS, or TS tools to pinpoint/figure out what was going on. I stumbled on a solution (install subnet router on a Windows box), and from there I searched and found others with that issue. Lost half a day in emergency mode over that!

* Better tooling to determine why it's falling back to DERP instead of direct for remote clients. DERP relays should be an absolute last resort to provide connectivity for Business-plan-level customers (very slow), and the way TS works just assumes any connectivity is fine.

Overall, the simplicity and abstraction of complex VPN networking is wonderful, but if you have issues or advanced needs, you are immediately thrust into the low-level UDP/NAT/STUN world you were trying to avoid. At that point, you're better off using a traditional VPN (WG, OpenVPN, or heaven forbid, IPSec), because it ends up being more straightforward (not easier) without the abstractions and easy-button stuff.

replies(10): >>43628638 #>>43628773 #>>43629221 #>>43629247 #>>43629638 #>>43630250 #>>43630297 #>>43630660 #>>43631345 #>>43674964 #
1. lo0dot0 ◴[09 Apr 25 10:33 UTC] No.43630660[source]▶
> NAT/STUN world you were trying to avoid

The clean way to build this is with firewall configuration, opening ports, and static IPs. NAT/STUN and dynamic IPs are just a hack and I don't understand why people pretend this is an acceptable solution for professional networking. Working around an infrastructure that isn't a natural law but can be changed at our will seems like a big waste of time.

replies(2): >>43630769 #>>43630999 #
2. supermatt ◴[09 Apr 25 10:55 UTC] No.43630769[source]▶
> I don't understand why people pretend this is an acceptable solution for professional networking

Because it IS acceptable for many cases.

Many businesses don't operate in such a way as to have centralised infrastructure solely for providing internal networking, nor would they want to add the additional administrative or unnecessary routing overhead.

Even locations that would traditionally be considered highly centralised often have some form of dynamic network fabric as an overlay. Pretty much the entirety of cloud infrastructure runs on such systems, and they seem to do OK.

replies(2): >>43630880 #>>43630910 #
3. lo0dot0 ◴[09 Apr 25 11:14 UTC] No.43630880[source]▶
Dynamic IP addresses typically also have a forced disconnect at a regular interval. Not really what I want to host services on.
replies(1): >>43630993 #
4. lo0dot0 ◴[09 Apr 25 11:17 UTC] No.43630910[source]▶
Also DERP relays having QOS that isn't controlled by myself and I have to hope to get bandwidth through doesn't exactly make me confident about the solution
replies(1): >>43630980 #
5. supermatt ◴[09 Apr 25 11:29 UTC] No.43630980{3}[source]▶
Sure, but your data is only getting relayed through DERP servers if it cant otherwise establish a direct p2p connection. This can usually be resolved at either side of the connection - if you know about it (which is what the parent was suggesting could be made more clear).

As for your bandwidth concerns in the case of needing to relay, you can even set up your own relay (https://tailscale.com/kb/1118/custom-derp-servers), which would satisfy your desire to be more centralised (i guess you could force all traffic through it, but cant think why you would want to) while still allowing the flexibility of the overlay that tailscale provides.

replies(1): >>43632096 #
6. supermatt ◴[09 Apr 25 11:32 UTC] No.43630993{3}[source]▶
That seems like even more reason to use an overlay - it abstracts all that instability away and gives you a consistent, secure network regardless of what the underlying IPs are doing. Obviously peers can have static IPs too if you think that makes them more stable to routing changes (it doesn't).
replies(1): >>43632051 #
7. udev4096 ◴[09 Apr 25 11:34 UTC] No.43630999[source]▶
Who said you can't do both? NAT makes things easier and you can still properly configure your firewall to keep track of all the NAT traversal rules
8. lo0dot0 ◴[09 Apr 25 13:47 UTC] No.43632051{4}[source]▶
Do you really think that a tailscale VPN is necessary to deal with link failures? It is not BGP and SD-WAN or MPLS l2 VPN can do that.
replies(1): >>43632935 #
9. lo0dot0 ◴[09 Apr 25 13:51 UTC] No.43632096{4}[source]▶
I never said I had a desire to be more centralised. I just said that static IPs and open ports remove the necessity for hole punching/STUN. You can have multiple sites without a central and all use static IPs and open ports.
replies(1): >>43632984 #
10. supermatt ◴[09 Apr 25 15:01 UTC] No.43632935{5}[source]▶
I didn't mention Tailscale. I said "overlay", and both SD-WAN and MPLS L2 VPN are overlay networks.
replies(1): >>43633690 #
11. supermatt ◴[09 Apr 25 15:06 UTC] No.43632984{5}[source]▶
I was replying to your comment about you wanting to control QoS for relaying.
12. lo0dot0 ◴[09 Apr 25 16:09 UTC] No.43633690{6}[source]▶
Idk what you mean with routing instability. Changes to routing as a result of failures are a feature not the problem.
replies(1): >>43634927 #
13. supermatt ◴[09 Apr 25 17:39 UTC] No.43634927{7}[source]▶
You said "Dynamic IP addresses typically also have a forced disconnect at a regular interval.", which is false in pretty much every DHCP scenario I have ever seen.

A change in an IP lease should result in no downtime whatsoever, because addressing is not the same as routing. A routing change would have exactly the same effect on a static IP.

I then pointed out that an overlay network means you don't have to worry about that anyway.

I think you need to reread whatever comments you think you are responding to, as there is clearly something out of sync with your replies.