[HN Gopher] Taildrop was kind of easy
___________________________________________________________________
Taildrop was kind of easy
Author : tptacek
Score : 314 points
Date : 2021-06-12 00:49 UTC (1 days ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| mikevm wrote:
| Did Tailscale introduce any security measures to their
| Coordination Server? Last I checked the coordination server is
| basically controlled by them and they could easily just insert
| any of their own pubkeys and infiltrate your network.
|
| Even supporting WireGuard's Share Secret feature would be a
| start.
|
| As long as that's not addressed, not a chance in hell I'm going
| to deploy this.
| [deleted]
| iFreilicht wrote:
| You can host your own coordination server, right?
| mikevm wrote:
| Last I checked you cannot.
| Nekit1234007 wrote:
| https://github.com/juanfont/headscale
| mikevm wrote:
| This is a 3rd party implementation. The official
| coordination server is not open source.
| Nekit1234007 wrote:
| But you _can_ host your own coord server, right?
| tyingq wrote:
| It does look like it's missing some functionality that
| could be key (DNS, ACLs, namespaces). But, pretty neat
| that it exists, given _" The purpose of writing this was
| to learn how Tailscale works"_.
| juanfont wrote:
| We do have support for separate namespaces/tailnets, and
| we will be adding ACLs soon...
|
| PRs welcome :)
| ukj wrote:
| Ahhh, the illusion of control. The fine line between prudence
| and paranoia.
|
| Do you also manufacture your own silicon in fear of being owned
| by your hardware vendors?
|
| Write all your own software?
|
| In fear of being owned by zero days in open source?
| antonvs wrote:
| Those aren't really comparable situations to an externally
| hosted "coordination server" which explicitly allows a third
| party to control access to your internal networks.
|
| Security breaches happen every day, with serious
| consequences. These are real threats, and there are ways to
| mitigate against them.
|
| A target like that coordination server is particularly risky
| because, as we saw with the massive Solarwinds attack,
| attackers will look for and expend effort to compromise the
| most attractive targets, and that's a particularly juicy one.
|
| Dismissing such threats with false equivalences is a pretty
| good way to find yourself on the wrong side of a security
| breach.
| tyingq wrote:
| Seems like it would be particularly tough to secure that
| coordination server. It handles metadata about not just
| nodes, but routing, ACLs, DNS, pre-auth keys, etc. And
| apparently in a way where it needs to understand the data
| versus just passing on encrypted bits that it can't read.
|
| I guess you could split it in half, and pair it with some
| actual service that the customer runs, and let it just be a
| dumb relay of encrypted/signed/whatever data.
| ukj wrote:
| They are exactly the same situation. When you run other
| people's code you are explicitly giving them control over
| your stuff. Ken Thompson pointed this out back in 1984. (
| https://dl.acm.org/doi/pdf/10.1145/1283920.1283940 )
|
| Either you trust the entity whose code you are consuming or
| you don't.
|
| Do you trust WireGuard to not get owned via a supply chain
| attack? Like Solar Winds.
|
| Do you trust any open source project you currently use to
| be free from bugdoors? Like University of Minnesota
| recently demonstrated by submitting intentionally-
| vulnerable patches to the Linux kernel.
| jerf wrote:
| There a significant difference. When I run code, it is
| isolated from the people who wrote it. Someone providing
| a github library I compile into my code has no ability to
| later _unilaterally_ come in and modify it. There is a
| gate where I have to ask them in, and I do tend to read
| the diffs first. There are only isolated windows of
| temporal vulnerability where I have to trust them, with
| mechanisms for dealing with that coherently.
|
| An always-on service is an ongoing, continuous trust
| relationship with continuous temporal vulnerability
|
| Consequently, while I can reasonably safely apply a lower
| bar of trust to libraries and code, someone asking to be
| continuously trusted must be held to a distinctly higher
| standard.
|
| It is can be valid to trust that as well, but you're
| operating from a crippled starting point for your
| security engineering if you don't see those as separate
| categories of issues to address.
| ukj wrote:
| >I do tend to read the diffs first.
|
| You are lying to yourself.
|
| You are necessarily claiming that a single person (you)
| is capable of adequately verifying the trustworthiness of
| the work of hundreds (perhaps even thousands) of
| developers.
|
| That's just the story you tell yourself to convince
| yourself that you are in control.
|
| Mean while FAANG have been doing it all wrong by hiring
| thousands of security engineers. They should've hired
| you.
| ukj wrote:
| >Consequently, while I can reasonably safely apply a
| lower bar of trust to libraries and code, someone asking
| to be continuously trusted must be held to a distinctly
| higher standard.
|
| Also, this seems backwards to me. You trust Tailscale at
| the network layer. If they abuse your trust to inject
| routes/keys your machine becomes network-reachable but
| all of your other controls are still in tact.
|
| That's not true when you applications violate trust.
|
| You can do AppSec if you don't trust the network. You
| can't to NetSec if you don't trust the application.
| kawsper wrote:
| I have been looking for a more user-friendly setup for our
| company, we're currently using OpenVPN with Viscosity as a
| client.
|
| Tailscale was on the list for services to check, but if what
| you say is true, then I will look elsewhere.
| mananaysiempre wrote:
| For a FOSS solution (now that ZeroTier no longer is one),
| there's Nebula, but you'll have to operate your own central
| node. That's nothing compared to maintaining the hell that is
| IPsec or even OpenVPN, though.
|
| Even bare Wireguard is a joy to set up, to my endless
| surprise, if you're fine administering things as a
| traditional small-scale LAN, manual routing and all.
| api wrote:
| We want ZeroTier to be FOSS. We just need to find a way to
| do that without allowing someone to take and rebrand it and
| write us out.
|
| ZT is vulnerable to this because we actually try to make
| everything decentralized and self hostable. We are not
| making a cloud silo play where we try to lock everyone into
| our hub to do their networking, so we have to be able to
| monetize by licensing as well as SaaS. Our SaaS is
| optional.
|
| This wasn't an issue a decade or two ago when existing FOSS
| licenses were created. It's an issue now, and is why other
| people working on decentralized easy to set up systems like
| CockroachDB use the same license we do. If CockroachDB were
| liberal FOSS someone would fork it and slap their name on
| it and scoop them, since by not having to do the hard work
| of actually developing it they could focus exclusively on
| marketing.
|
| (You can self host ZT controllers, and roots become easier
| to self host in the next major release. Once we do that the
| protocol could theoretically outlive the company with no
| loss of functionality including its unified namespace.)
| mwcampbell wrote:
| I think people who insist on FOSS are demanding too much.
| Your choice of license is very reasonable. Don't let the
| purists and freeloaders get you down. (No, I don't yet
| use Zerotier, but maybe I should.)
|
| More generally, I like what you said a little while back
| in the thread about the Mighty remote browser [1]:
|
| > (2) The hopelessly naive idea that "information wants
| to be free" and everything has to be "free" (as in beer)
| needs to die, be cut into a thousand pieces, burned,
| encased in concrete, and sunk to the bottom of the ocean.
| Nothing is free. Software takes a vast amount of labor to
| produce, and that must be funded. If it's not funded
| directly and honestly it will be funded indirectly and
| dishonestly (surveillance capitalism, cloud lock-in,
| etc.). "Everything has to be free" and piracy actually
| help push us toward a surveillance capitalist panopticon
| future.
|
| That point should be front and center in all discussions
| on FOSS sustainability (or lack thereof).
|
| [1]: https://news.ycombinator.com/item?id=26970617
| mananaysiempre wrote:
| It's not my intention to accuse or condemn you, in that
| while I do dislike the direction you've chosen, I don't
| think you are being intentionally or unintentionally
| malicious. It is also hard not to love the tecnhical work
| you do and the way you've not only struck out in the
| corporate networking badlands but also taken up the
| mantle of Hamachi, which has lain unclaimed for way too
| long.
|
| You're absolutely brilliant (like Cloudflare), your goal
| does not seem evil (similar to that of Cloudflare),
| neither do the consequences of achieving it (somewhat
| less like Cloudflare), and you haven't done outright evil
| things like patent clever but fundamentally simple tricks
| (have I mentioned I'm conflicted about Cloudflare?). And
| when all is said and done, you do have to pay your bills,
| and only you can say what works and what does not in that
| respect.
|
| So I applaud you when you say, loudly and honestly, that
| the goal of your licensing model is to pay for the
| development by making yourself an essential part of it. I
| believe you when you say your work couldn't exist
| otherwise. But my mental model of (dev- and knowledge-of-
| humankind-centric) open source (unlike that of user-
| centered free software) is that its very essence is the
| original developer making themselves _un_ essential or at
| least not using legal threats to preserve their special
| position.
|
| Thus I am explicitly _not_ saying that your non-open-
| source approach is evil--that _would_ be unjustified
| purism; morality judgments are difficult and best not
| employed as one-sided proclamations. I am _not_ expecting
| that you will go home ashamed or mend your dastardly
| ways, because you have nothing to be ashamed of, your
| ways are not dastardly, and I have no idea how you could
| mend them and still survive. I _am_ saying that your non-
| open-source approach disagrees with the very core of the
| open source idea as I best understand it, not on a purist
| technicality but in a fundamental way.
|
| Bruce Perens co-founded the OSI. He seems to have given
| up on the idea of open source in the age of mainframe
| providers wielding armies of star programmers, and
| probably would not have any issue with your strategy. I
| am younger and have not given up yet, so I look upon your
| strategy with sadness and a longing for a better world.
|
| Bruce Perens is much smarter than me in more ways than
| one.
| api wrote:
| I really agree with your sentiment to a point, but the
| problem as I've written elsewhere (ad nauseam) is that
| software isn't free. Software, particularly easy to use
| software, is extremely labor intensive. If FOSS is about
| developers writing themselves out of the equation, it
| means nobody can make a living making it. If nobody can
| make a living making it, that puts a pretty huge limit on
| how much resources can be put toward making FOSS better.
|
| Closed silos don't have that constraint so they will win
| by sheer muscle power.
|
| The BSL (our current license) sort of sucks, and I look
| at it as a stopgap until we can come up with something
| better. I have some ideas, but they need to be developed
| and so far I have not had time to develop them further
| since coding and running a company are fairly demanding.
|
| They deserve a blog post at least.
|
| Outstanding reply BTW.
| api wrote:
| You can self host ZeroTier controllers, which are the things
| that control network access. See the controller subfolder of
| github.com/zerotier/ZeroTierOne.
|
| Roots in ZeroTier are harder to self host right now (it's
| getting easier in the future) but they are just dumb
| STUN/TURN equivalents. They have no power to grant access and
| can't even see what networks you join or what you are doing.
| arthurcolle wrote:
| I highly recommend you check out ZeroTier. I've found
| WireGuard setup to be non-trivial and extremely error-prone,
| but with ZeroTier there's a web UI that you can add new
| services and machines from, all as one logical "network"
|
| I believe that the free tier is capable of running clusters
| of up to 50 machines. Really nice to use + truly trivial to
| set up.
| cpach wrote:
| It's also possible to use Wireguard without Tailscale.
| mikevm wrote:
| Or https://www.zerotier.com/
| apenwarr wrote:
| Post author here. I'm happy to answer any questions / respond to
| any rants if you like.
| oarsinsync wrote:
| In a world moving towards "zero trust networking", this appears
| to be going in the opposite direction, where the network is now
| being implicitly trusted.
|
| This enables unauthenticated file transfers between hosts on
| the same network.
|
| Given the world we live in today is that RCE vulnerabilities
| are relatively common, what happens when host1 gets some
| malware and uses this to transfer itself onto host2?
|
| I assume this has been considered, and it's been decided that
| the convenience of the feature outweighs the security and
| reputation risk considerations?
| apenwarr wrote:
| Someone else mentioned that basically malware on your machine
| is expected to bypass all security layers. So we're basically
| saying "the 'new' network layer is now as trustworthy as the
| app layer" rather than claiming everything is perfect, you're
| right.
|
| This is one reason we limited taildrop to only transfer
| between devices owned by a single user for now, and only to
| drop files into controlled locations. Tailscale also has ACL
| policies for when you don't trust all the endpoints to just
| do anything.
| carlosf wrote:
| I guess in an ideal world where everything in your org is
| behind MFA, app authentication and protected from denial of
| service, then solutions like tailscale would not be needed.
|
| But my personal experience is that most software is
| completely hostile to good security practices and you end up
| having some perimeter security as well.
| iso1210 wrote:
| Isn't the tailscale work more to do with authenticating hosts
| than the network. You trust all communication decodable by a
| trusted public key.
|
| That still allows malware on a trusted end device to connect
| to you, but then if you've got malware on the box chances are
| it will have access to the private keys, authentication
| cookies etc, anyway - at least currently.
| JacobiX wrote:
| I use Tailscale every day I like the simplicity of setting up a
| new node. My problem is that I don't know how to separate my
| nodes into isolated groups, so my question is does it support
| some form of multi-tenancy ?
| ricardbejarano wrote:
| There is ACL support on the Admin console.
|
| Lets you choose which users/machines/tags can talk to who.
| Tags are like groups.
| JacobiX wrote:
| Thank you, yes we are using this feature but I was thinking
| of something like creating separate isolated network for
| each group of machines. For example I manage two different
| cloud infrastructures that don't share anything in common.
| It would be more convenient if I could place them in
| different tenants.
| ignoramous wrote:
| re:localapi: Are these httpd instances? If so, are they run on-
| demand or are always running? Curious how this plays out on
| mobile devices with regards to power consumption?
|
| re:whois: I presume this is in control of a central identity
| service. I see that the private tailscale network is (mostly)
| p2p and (always) e2e, so wondering if you envision a future
| where the tailscale network goes decentralized without a
| central control ala BitTorrent / LimeWire (despite [0])?
|
| re:peerapi: Excuse my naivety, but couldn't this binary
| transport be used for file transfers too? Or, does http simply
| provide too many (file transfer) options [1] to not bother re-
| implementing it in a custom protocol?
|
| Thanks.
|
| [0] https://apenwarr.ca/log/20201227 (when's vol.2 out?)
|
| [1] I can see screensharing up next, a keybase-like chat
| client, and even live video / event streaming?
| apenwarr wrote:
| The localapi is indeed an http server built into the
| tailscaled process, which is written in Go. Since we already
| had an http client in there, the net new code to add an http
| server is quite low. And it doesn't take any battery unless
| it's being queried. I think people underestimate how cheap
| http can be (once you've paid the up front cost, anyway).
|
| You've correctly guessed that blog link [0] that explains the
| reason I don't think we'd ever want to try making a
| distributed coordination service. Most importantly, corporate
| customers absolutely love having a single control and
| registration point for every corporate authorized device on
| their network (and thus, a way to instantly deauthorize
| stolen devices). What we're going to do though is add private
| audit trails and tamper proofing, kind of like TLS
| certificate transparency, so that the central instructions
| can be validated in a decentralized way, if that makes sense.
| More on that later. :)
|
| Re: peerapi, there are lots of ways to build app layer
| protocols once you have tailscale making the connection
| itself easier. We picked http since it was the fewest lines
| of code and it makes an easy example.
|
| Re: live video, Jitsi already works fine on a tailscale
| network if you want to try that.
| ignoramous wrote:
| > _And it doesn't take any battery unless it's being
| queried. I think people underestimate how cheap http can
| be..._
|
| Curious about the underlying design decision on why a
| separate peerapi layer if a golang http/2 server is
| listening already (or is peerapi running over http, too)?
|
| > _What we're going to do though is add private audit
| trails and tamper proofing, kind of like TLS certificate
| transparency, so that the central instructions can be
| validated in a decentralized way._
|
| Exciting. Reminds me of:
| https://blog.okturtles.org/2014/09/the-trouble-with-
| certific... and https://book.keybase.io/docs/teams/sigchain
|
| > _...there are lots of ways to build app layer protocols
| once you have tailscale making the connection itself
| easier._
|
| True. My previous employer built an internal service
| similar to tailscale but it worked over bluetooth, wifi-
| direct in addition to ICEing NATs out. It made device
| discovery, cross-app, cross-device, cross-service
| communication super easy.
|
| Thanks again.
| mwcampbell wrote:
| > I wrote our Windows Taildrop GUI. I reserve the right to make
| fun of it.
|
| Is the GUI open source somewhere?
| mwcampbell wrote:
| Found the answer, in the headscale readme:
|
| > Everything in Tailscale is Open Source, except the GUI
| clients for proprietary OS (Windows and macOS/iOS), and the
| 'coordination/control server'.
|
| Keeping the GUI clients for proprietary operating systems
| closed-source is certainly a valid business decision. It's
| just unfortunate that it means we don't get to fix any issues
| we find that may matter more to us than they currently do to
| the Tailscale team, e.g. accessibility.
|
| Edit: Yes, I know, to be fully consistent on this point, I
| should run an open-source OS. But then, the proprietary
| operating systems have accessibility teams, while presumably
| Tailscale does not.
| ithkuil wrote:
| Awesome work, I wish I could use it. Unfortunately I use
| tailscale at work too and until
| https://github.com/tailscale/tailscale/issues/713 I'm turned
| off from using tailscale also for my personal stuff since I
| don't want to physically switch to a different set of machines
| for work and personal projects.
| supermatt wrote:
| Im still a bit confused about the "without the cloud" aspect.
| It seems that you still need NAT traversal, which means an
| external STUN server, and a relay for NATs that cannot be
| traversed - as well as a coordination/signalling broker. Surely
| those require some services "in the cloud"?
| apenwarr wrote:
| In Tailscale, much like in SDN or SD-WAN, we think of the
| network in two parts, the control plane and the data plane.
|
| The data plane is how the bulk of your packets get sent from
| one place to another, which in Tailscale is peer-to-peer (as
| long as your network is not completely blocking NAT traversal
| for some reason). Even if NAT traversal is blocked and we
| have to relay your data through the cloud (through our DERP
| network) to make it work, the data plane is still end-to-end
| encrypted using private keys that only exist on each node.
| The private keys never leave each node. The DERP servers are
| just relaying opaque byte streams, like any IP router would
| do.
|
| On the other hand, the Tailscale control plane uses a central
| coordination service. It's used to exchange public keys and
| STUN information between nodes, but this is a tiny amount of
| information updated rarely (and therefore reasonably cheap
| for us to handle at scale). These public keys are not enough
| for an attacker (us or anyone else) to be able to decrypt
| your data traffic.
|
| So when we say taildrop never sends your files through the
| cloud, that's because taildrop exists entirely inside the
| data plane, sending data through e2e encrypted tunnels that
| have already been established with the help of the
| coordination service, STUN, etc.
|
| Because the coordination service is cheap for us to run, we
| can have a really generous Tailscale free plan without losing
| all our money. The paid plans are intended to be for
| "corporate network" situations where people want more
| centralized controls, audit trails, and so on.
| judge2020 wrote:
| Really great insight into your pricing structure (just
| today I was wondering if you were just burning money with
| the generous free plan), thanks!
| adtac wrote:
| >as long as your network is not completely blocking NAT
| traversal for some reason
|
| Out of curiosity, how often does this happen in practice?
| Also, how would you even do this? Isn't NAT traversal a
| direct consequence of how firewalls work and always
| possible?
| apenwarr wrote:
| A trivial example is networks that totally block UDP and
| only allow TCP traffic on port 443, say.
|
| Tailscale has an article called How NAT Traversal Works
| with considerably more gory details if you're interested.
| jimmySixDOF wrote:
| Session Border Controllers were a big part of any carrier
| VoIP deployment and focused on essentially the same problem
| : using the signaling plane to normalize a separate direct
| endpoint packet flow across variable networks and devices.
| You are implementing this same logic in your SD-WAN or do
| you use like an acme packet (->oracle) box now you operate
| at scale ?
| oezi wrote:
| Does Tailscale include automatic client node updates in any
| way? How to ensure all clients are up to date at any time?
|
| How do you assign devices to logical networks?
|
| How many virtual networks can be run concurrently on a single
| device?
| apenwarr wrote:
| MacOS, iOS, and Linux clients can use your native OS updates.
| Windows needs to be updated by hand or with something like
| chocolatey or MDM. But more importantly, we have a policy of
| not breaking old clients if we can possibly avoid it. So far
| we have never deprecated old clients. We extend our protocols
| in a backward compatible way, because unilaterally breaking
| your network infrastructure... really sucks.
|
| The way tailscale networks (tailnets) work is probably not
| how you're used to thinking about them. Each node has its own
| view of the world, based on which nodes and services are
| shared with it in particular. We have security policy
| settings per domain, and a node sharing UI that lets you
| share any of your devices with anyone else.
|
| The default model is that all devices belonging to someone in
| the same domain, say tailscale.com, can see each other. But
| we're working on making that even more flexible since it
| doesn't always do what you want for huge orgs (like
| universities).
| oezi wrote:
| > ... updates ...
|
| Do you think it is sufficient to rely on update channels
| via distributions? Wouldn't a bug in your code potentially
| expose an internal node to the internet?
|
| > Each node has its own view of the world
|
| I haven't read the docs enough, but can a node belong to
| many domains at once? If so, does it need one port per
| domain that it is shared on?
| xena wrote:
| > Do you think it is sufficient to rely on update
| channels via distributions?
|
| Tailscale employee here. Most officially supported
| distributions use our own package repo server
| (https://pkgs.tailscale.com), which would pull Tailscale
| updates in your normal system updates. The other
| distributions that aren't in the package repo server
| (Alpine, Arch, Gentoo, NixOS, Void Linux, etc.) use
| packages made by the distribution themselves. We do our
| best to make sure they get updated (contacting the
| maintainers can be a slog at times), but we do not
| completely control the update process for them.
|
| > I haven't read the docs enough, but can a node belong
| to many domains at once? If so, does it need one port per
| domain that it is shared on?
|
| Not currently, follow this bug
| (https://github.com/tailscale/tailscale/issues/713) to be
| updated on the details for this. You can sorta hack
| around it with node sharing
| (https://tailscale.com/kb/1084/sharing/), but that's
| unidirectional instead of bidirectional.
| zaroth wrote:
| So my immediate thought was, what if I want to use Tailscale as a
| backend fabric for enabling a new P2P application?
|
| It doesn't seem like a scenario / use case envisioned in their
| pricing page.
| apenwarr wrote:
| The idea is to get there eventually, and taildrop is the first
| example/experiment in that area.
|
| In theory a bunch of individuals on the free plan should be
| able to build arbitrarily complex networks by using the (also
| free) node sharing feature:
| https://tailscale.com/kb/1084/sharing/
|
| In practice, probably needs more stuff added before that's
| truly realistic. But we're always looking for feedback on how
| to make it easier.
| kodablah wrote:
| This was my first thought as well. I wonder if what they refer
| to as the control plane[0] could be a DHT that contains keys
| instead. But as I thought more, I wonder what benefit a VPN-
| based fabric for P2P would have over protocol/application-level
| encrypted content. Granted the NAT busting features can help on
| their own, but otherwise I struggle to see the benefit assuming
| the protocol has encryption and P2P built in (I am probably
| just missing something).
|
| 0 - https://tailscale.com/blog/how-tailscale-works/
| tyingq wrote:
| I wonder how uneasy this sort of nicely documented and packaged
| user-space networking and nat traversal is making IT admins. It
| seems like it's pretty easy to, for example, create an internet
| facing service that pulls from internal company data sources.
| With user-space tunnels that probably aren't very easy to find
| from the IT admin perspective.
|
| I get that Tailscale didn't invent this capability, but they do a
| nice job of showing how it would work, some of the pieces
| (wireguard-go), and so on.
|
| They do seem aware:
| https://github.com/tailscale/tailscale/issues/204
| vxNsr wrote:
| Seems like a great service if you're already using tailscale.
| wrs wrote:
| Indeed, the article did a good job of making me wonder how long
| it'll be before we're all using Tailscale.
| maddyboo wrote:
| Seriously, give it a shot if you haven't already. It's dead
| simple to install and "just works."
| jbverschoor wrote:
| I actually use both. Here are my observations:
|
| - Tailscale is an IPv4 vpn. Zerotier is a virtual ethernet
| switch.
|
| - Tailscale does not do ipv6, ipx, or any other protocol.
| Zerotier doe.
|
| - Zerotier supports multiple networks. Tailscale only has 1
| network per account. So it's not possible to be connected
| to WORK1, WORK2, HOME at the same time.
|
| - Zerotier handles broadcast / multicast perfectly.
|
| - Tailscale uses wireguard, whichs means it's probably
| going to be more compatible
|
| - Tailscale forces SSO on certain domains (for example
| gmail). I really don't like being forced to use this. It's
| nice to have the option, but usually they require too much
| information.
|
| - Tailscale uses login credentials to link machines, vs
| using machine keys in zerotier. I prefer zerotier's method,
| as I really don't want do the whole login flow all
| machines.
|
| - Tailscale by default expires the sessions after X amount
| of time. Super annoying when you discover things are not
| working, because you didn't change a setting somewhere
|
| - On mac, tailscale uses a VPN tunnel. Zerotier creates a
| virtual interface. I prefer zerotier's method.
|
| - Because of this, tailscale is available via the appstore
| (mac). I like that. Both are available on the ios app store
|
| - Both have some sort of SDN language / configuration.
|
| - Tailscale is only an ACL type config, which is good
| enough for most
|
| - Zerotier's is more extensive, and allows cool things such
| as redirecting packets to a different machine for
| inspection. Great for security monitoring and other stuff.
|
| - Tailscale comes with a built-in dns, which is nice.
| Zerotier is working on that
|
| - Zerotier has public networks. While I think it's a bad
| idea, it's pretty fun and dangerous
|
| In terms of stability and performance, they're both stable
| and fast. Somehow zerotier does not get as much love as
| wireguard. Or nobody talks about it ;-)
|
| Tailscale seems to forcus more on higher layer apps
| (filedrops, service discovery (just a portscan), simple
| firewall rules), while Zerotier seems to focus more on the
| technicalities. Tailscale is trying to look for which value
| adding features are popular amongst clients.
|
| This makes sense, as tailscale simply uses wireguard, and
| zerotier is their own tech. Zerotier seems to be run by
| networking people. This is also the things that works
| against zerotier.. UI is clunky, the SDN language is
| difficult, no service discovery.
|
| Imo zerotier's updates and development is very slow. Not
| sure why.. Maybe they lack a roadmap.
|
| For zerotier to be easier to use, they could create a
| visual editor for the networks, by actually showing a
| switch, using cables on the ports, and different colors for
| different rules. This is more in line of what they do
| (global ethernet switch), instead of a VPN.
|
| Also, I think zerotier should do more official integrations
| with routers / nas. Wireguard at a certain point will be
| integrated in all routers, because it's in the linux
| kernel.
| xena wrote:
| > Tailscale does not do ipv6
|
| Tailscale does!
| https://github.com/tailscale/tailscale/issues/19
| $ ip addr show dev tailscale0 4: tailscale0:
| <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc
| fq_codel state UNKNOWN group default qlen 500
| link/none inet 100.67.184.57/32 scope global
| tailscale0 valid_lft forever preferred_lft
| forever inet6
| fd7a:115c:a1e0:ab12:4843:cd96:6243:b839/128 scope global
| valid_lft forever preferred_lft forever
| brainbag wrote:
| What problems does it solve? Is it just a "shared network"
| VPN? The web site says what it is but not why.
| gravypod wrote:
| It's BeyondCorp done at a network layer. You have
| cryptographic trust that traffic from specific IP ranges
| are specific people, you get a flat network topology for
| your infra/team/etc, and it works in the most hostile
| network environments.
|
| The tailscale team has gone through great lengths to
| handle a lot of edge cases and hacks in the
| infrastructure at many corporate networks.
| alisonkisk wrote:
| It gives you access to your machines from across the
| Internet.
| dsyrk wrote:
| It seems to basically be tinc but "modernized"
| solipsism wrote:
| That's what it is not why. For most people the response
| to this will be "why would I want to do that?"
|
| There may be good reasons. But they'll need to be
| explicitly spelled out for most users.
| skybrian wrote:
| It sounds like you'd want it if you have machines on your
| local network that you want to use when you're not at
| home. (Or you have some other machines somewhere else.)
|
| If you just have mobile devices and always take them with
| you, or don't care about accessing a desktop computer
| when you're away, it's maybe not that interesting?
| encryptluks2 wrote:
| What about printers/scanners? Can it make your entire LAN
| available over a single device?
| dave_universetf wrote:
| It can, see https://tailscale.com/kb/1019/subnets/ .
| There's more work for us to do for more "automagic"
| behavior. For example, I want my home desktop to offer
| proxying to my printer without having to set up a full-
| fat subnet router.
| Wintereise wrote:
| What does it do that Zerotier doesn't already? I've been
| using that for a few years now, works flawlessly.
| atonse wrote:
| That you can get it up and running in 5 minutes. No joke,
| I did it one day before jumping into the car to go to the
| park to work on a day with nice weather.
|
| It let me SSH back into my Mac Mini to compile elixir and
| run VS Code Remote and not kill my battery, but still
| have zero latency UIs over cellular tethering.
|
| I tried Zerotier a few years ago and maybe I just did
| something wrong but I couldn't get it working for an hour
| and gave up.
| jbverschoor wrote:
| what do you mean. zerotier is literally just running,
| creating a network in the dashboard and allowing your
| machines
| jbverschoor wrote:
| Also, zerotier supports non-IP protocols. IPX for example
| which is pretty cool.
| viraptor wrote:
| Not sure if 5 years ago it was much different, but I've
| been using it for ~3 years and the process is trivial.
| Setup your account, install client, join your network,
| click "auth" on the website by the new client. It just
| works.
| jbverschoor wrote:
| Was the same 5 years ago
| Wintereise wrote:
| I'm not sure where it went wrong for you, but I had
| Zerotier up in 5 minutes as well.
|
| Basically sign up for account -> install -> allow to join
| network in Dashboard. That was it.
| implying wrote:
| I've deployed it to my larger-than-average home network with
| great success. A device can roam outside of the network and
| still access intranet sites and services, and I can remotely
| access family devices for helpdesk tasks.
|
| My only complaint is that there is no good alternative to
| authentication other than using Google for small deployments
| like this. I don't want to pay an auth provider, and none of
| them offer a simplified plan for 3-4 users.
| iso1210 wrote:
| Do services like airplay and other bonjour based protocols
| work?
| mercora wrote:
| the official wireguard implementations only do unicast
| afaict.
| oezi wrote:
| > I can remotely access family devices for helpdesk task
|
| Aren't you afraid that a family member compromises "your"
| network? I would be cautious to let my parents operate
| within my intranet unchecked.
|
| Does Tailscale have any means to monitor or tie this down
| without being a drag?
|
| I am still stuck with doing TeamViewer into family devices,
| because it seems less risky.
| blowfish721 wrote:
| I would probably use their isolation/segmentation
| features for this if I ran something simular. Like you
| said I wouldn't trust my own devices let alone family
| members to have full access to everything.
| https://tailscale.com/kb/1018/acls/
| macintux wrote:
| From the site it looks like GitHub works; is that not the
| case?
|
| I'm definitely not using Google for auth if I can avoid it.
| atatatat wrote:
| So, Google or Microsoft, then.
| Jtsummers wrote:
| I think that's new-ish, I'd have used it if it were an
| option when I created my account.
| dave_universetf wrote:
| It's "launched this week" new, yeah. We don't have a way
| to migrate between auth providers yet, but if you feel
| strongly you could log out your devices and sign back in
| with github auth. That'd create a completely new tailnet
| tied to github auth instead of google.
| PostThisTooFast wrote:
| Whatever THAT is.
|
| Another douchey HN headline.
| MorganGallant wrote:
| The really interesting idea here is that once you change the
| frame of reference, or start from a different technical basis,
| features like Taildrop become incredibly easy to build and design
| - it seems like it almost built itself. It seems like the same
| goes for interfaces or platforms... once you have a computer in
| your pocket capable of 11T operations per second, you get a lot
| of stuff "for free" right out of the box.
| bsder wrote:
| Sure, once you "Bust a NAT" sharing is stupidly simple.
|
| "Bust a NAT" is anything but easy, however.
| bookofsand wrote:
| Indeed. For those that started scratching their heads 'this
| is impossible', this deep dive from the Tailscale blog will
| be informative. Perhaps even entertaining, the birthday
| paradox may have a hand in it.
|
| https://tailscale.com/blog/how-nat-traversal-works
| iso1210 wrote:
| However in situations where you have say a Juniper SRX
| scrambling both source and destination ports on both sides
| of your nat, the birthday intersect is 2^32 rather than
| 2^16.
|
| With a Cisco ASA or Fortigate which tends to keep the same
| source port where possible you'll converge far more
| quickly. When there's a central server to help it's even
| quicker and most of the time will just work.
|
| (sometimes it's not possible to keep the same port when
| source-natting -- with two devices from 192.168.0.1:9000 ->
| 1.1.1.1:53 and 192.168.0.2:9000 -> 1.1.1.1:53, the second
| will have to have a mapping to non-:9000 source IP, but in
| my experience, Cisco, Fortigate and Mikrotik (thus linux)
| all support the "only change if needed" option)
| eru wrote:
| That reminds me of
| https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...
|
| Basically, Knuth was writing a beautiful but excessively low
| level program. His challenger wrote a dozen lines of shell-
| script.
| svat wrote:
| Not "his challenger"; it was not a contest. It would be more
| proper to say "his reviewer, the inventor of Unix pipes,
| using the review column to advertise UNIX(r)". See a previous
| discussion here:
| https://news.ycombinator.com/item?id=22406070
|
| Incidentally, a couple of days after that thread, the current
| fastest submissions (which, like Knuth, all use tries) were
| posted at the question https://codegolf.stackexchange.com/que
| stions/188133/bentleys... mentioned in a sibling comment.
| (AFAICT that comment should say "200 times faster", not "30
| times faster", but anyway in light of the original context
| it's not meaningful to compare the two approaches either for
| efficiency or ease of implementation or anything else.)
| nindalf wrote:
| Codegolf page with solutions up to 30 times faster than the
| McIlroy shell script solution - https://codegolf.stackexchang
| e.com/questions/188133/bentleys...
| eru wrote:
| Interesting, that they can only get 30 times faster with
| modern technology and more complications.
|
| I guess, if you really wanted to solve this fast, you'd
| massively parallelize.
|
| In any case, this was more about easy of implementation
| than about runtime speed.
| [deleted]
| abss wrote:
| For the taildrop author: I could see potential on this to be used
| in the enterprise blockchain area with a condition: make it easy
| to setup a virtual network in wich each member is manually
| approving public keys of the consortium members. Working with
| docker/kubernetes will also be good. Contact me (taildropfromhn
| at axiologic.net) if you want details. We will love to use such a
| VPN setup in a real blockchain project for pharma industry.
|
| For others: therr others that will appreciate the better security
| offered by using public key cryptography while still having a
| lightwight but decentralised setup?
| apenwarr wrote:
| You might like the Tailscale Machine Key approval feature. If
| enabled for your domain, no device can join your tailscale
| network unless they're manually approved by your network's
| admin or the API.
| _joel wrote:
| I wish tailscale would offer auth that isn't tied to the big SSO
| providers.
| colesantiago wrote:
| Is Tailscale / Taildrop fully open source? Such that I can set
| this up myself for my own purposes 1:1? Wanted to use Tailscale's
| service but saw this on the sign up page:
|
| > Sign up with your identity provider...
|
| This frightened me enough not to use Tailscale, I don't want
| Google / Microsoft sharing any more of my data. Is this still the
| case?
| bookofsand wrote:
| Skimmed through their excellent design docs. The code is open
| source, but requires running a centralized control plane sever
| and may also require running a data plane relay server to cover
| some relatively common NAT configurations.
|
| https://tailscale.com/blog/how-tailscale-works
| sbierwagen wrote:
| >Is Tailscale / Taildrop fully open source?
|
| Why would it be? It's a commercial service.
|
| >Such that I can set this up myself for my own purposes 1:1?
|
| I'm guessing both peers ping a central server in order to
| discover each other, which is why it's integrated with
| tailscale at all. If you're in the tiny segment of the
| population who is already paying for a server with a public IP,
| and have the technical ability to deploy services to it, I feel
| like it would be marginally less effort to just sftp the file
| to that server rather than try to clone the feature set of
| taildrop.
|
| Tailscale could theoretically publish a docker container that
| contains the guts of this service, but it'd be rather a lot of
| work, for no money.
|
| >>Sign up with your identity provider...
|
| I have not seen a lot of evidence that regular users care about
| identity provider privacy, seeing as how Facebook had 2.8
| billion monthly active users last quarter. That customer
| segment (half of the world population) might be more interested
| in signing up for the free tier of tailscale and getting magic
| file sharing than they would be in administering their own
| linux server.
| neolog wrote:
| > Why would it be? It's a commercial service.
|
| Open source is a good way to get community buy in, because it
| improves transparency and reduces lock-in. There are lots of
| open source commercial services, including the Tailscale
| client service.
| viraptor wrote:
| If you want an open version, ZeroTier provides a similar kind
| of seamless networking setup. I'm sure someone will implement
| an alternative to taildrop on top of it.
| sneak wrote:
| ZeroTier isn't open source / free software, it's only source-
| available.
|
| https://github.com/zerotier/ZeroTierOne/blob/master/LICENSE..
| ..
|
| I'm personally really tired of fake open source projects like
| this.
| apenwarr wrote:
| There's an open source project called headscale (not written by
| or officially supported by tailscale's team, but we like it)
| which you can point tailscale's clients at. Then your whole
| system is open source. You can also avoid using a central IdP
| that way, if that's what you want. (I strongly recommend
| caution about that, if you want good security. I know it's not
| popular to say so on HN, but most people running their own IdP
| will do it less securely than one of the big providers. It's a
| very hard job, akin to running a root CA.)
| inigojonesguy wrote:
| >There's an open source project called headscale
|
| This? https://github.com/juanfont/headscale
| juanfont wrote:
| Yup.
|
| Btw, there is no IdP support in Headscale. You need to have
| access to the machine where you are running it, and use the
| CLI to register your machines (or use a authkey, ofc).
| judge2020 wrote:
| Given you'd sign up with an email anyways, I don't see how it's
| sharing more data by using oauth versus a password.
| iso1210 wrote:
| If I share my email with tailscale that's sharing data
| between me and them, no third party involved.
|
| If I use an OAuth integration I'm involving a third party
|
| Some people use a third party email provider, but chances are
| they aren't supported (even if your mail provider offers
| oauth integration) -- the only support is with Google and
| Microsoft
|
| Now that aside, I support the idea of tailscale not creating
| its own identify provider. BYOI is far better than yet
| another supplier to leak information and yet another password
| to manage.
|
| If I were interested in integration with my company's SSO,
| I'm sure they'd be able to support our OAuth endpoint.
|
| For personal use, chances are you have an identity with one
| of the providers, and the information leaking to that
| provider (that you use tailscale) is minimal and seems like a
| good solution.
| e12e wrote:
| Nice tool. I wonder if it supports resuming downloads?
|
| Might have been better if they built on bonjour/zeroconf rather
| than make a "tailscale" api though... on the other hand, I guess
| bonjour/zeroconf works oob on tailscale anyway.
|
| Which makes this more of a marketing for a new api/app platform?
| mercora wrote:
| unless they do do something funky only unicast packets are
| routed in wireguard. bonjour/zerconf/mdns all use multicast or
| broadcasts for discovery. integrating some kind of service
| discovery relay would be possible though.
| e12e wrote:
| Hm, I thought I'd seen someone comment that mDNS worked for
| wireguard - but I haven't tried myself. I guess I can't move
| from ZeroTier for my home network yet.
| dave_universetf wrote:
| Not yet on resuming downloads. No principled reason, just
| haven't gotten to it yet.
|
| LAN discovery is handled by Tailscale's network engine, a
| couple layers of abstraction below the file sending. We're
| going to add some mdns stuff in there at some point (similar to
| WebRTC's privacy-preserving LAN endpoint discovery), but the
| benefit of running this all over Tailscale's network engine is
| that file transfer works exactly the same whether you're on the
| same LAN as the target, or halfway across the internet. The
| only variable is how fast the file moves.
| lilyball wrote:
| Wide-area DNS-SD exists too, it's not just for mDNS, so if
| this was built on a DNS-SD infrastructure then supporting
| devices off the LAN would be as simple as just offering a
| wide-area service enumeration and browsing domain.
___________________________________________________________________
(page generated 2021-06-13 23:01 UTC)