Hacker Newsnew | past | comments | ask | show | jobs | submit | hwpky's commentslogin

Pressure to service larger customers to capture higher revenues is inevitable for Tailscale given the scale of VC funding, valuation, and operating costs involved.

Trying to be all things to all people will inevitably dilute focus, and it’s understandable that OP might be looking at this sub-product and wondering where the value is for their use cases.

They’re probably not the only ones questioning whether they’re still part of Tailscale’s core ICP (ideal customer profile), either.

Edit: expanded ICP for clarity.


yes this inevitably happens to companies that can't grow infinitely, you pivot to enterprise because you can sell to one person that has the equivalent spend of thousands... it really is unfortunate for the individuals


As far as Fail2ban goes, using it to lock the door is good, but removing the door entirely is better.

Fail2ban is useful for limiting failed access attempts, but closing the SSH port altogether limits attack pathways to only trusted parties in the first place — assuming SSH isn’t meant to be publicly accessible.

There are many modern technology options for enabling private access without needing to open firewall ports, many are listed at https://zerotrustnetworkaccess.info

Of these, mesh overlay networks appear to be gaining the most traction lately, especially among the HN crowd.


This post is accurate, fail2ban does suck.

But that's not a reflection on the fail2ban maintainers, the engineering work that's gone into building it, its usability, bugs or indeed anything else connected to its implementation.

It sucks simply because it's solving the problem in the wrong way. There is no sensible security onion, or defence in depth model for open ports in front of private systems.

If the technical solution for keeping private, or limited access systems actually and effectively private on the public Internet requires open ports, it's the wrong solution.

Unless we're running services designed for public and anonymous access, exposing technologies like VPN servers, SSH or any other software for private consumption to the Internet is a mistake.

When we do this we're putting out invitations for abuse and pulling the burden of security responsibility onto ourselves. I'd argue however, that unless it's a full time concern for us, we're close to the project or maintainers, and able to contribute security fixes to source code, we're probably ill equipped to directly handle that responsibility and remain dependent on engaging with the surrounding security eco-system to remain secure.

I'm not knocking those security eco-systems, I'm just pointing out that there's a time lag inherent on depending on best-efforts from third parties which creates windows of vulnerability, and open ports on infrastructure ALWAYS puts us on the back foot. From getting patches applied in a timely fashion to the time and convenience cost of updating ACLs each time IPs change. Even if we get the maintenance tasks right 100% of the time, we're still open to the risks of something outside of our control happening, like zero day being sprayed across open ports.

The U.S. Government correctly issued an executive order mandating Federal Agencies move to adopt Zero Trust principles just six days after the Colonial Pipeline ransomware attack in 2021. Despite the marketing hype which has followed, if we take nothing else away from this motion, it should be that opening ports in our networks to access private systems using the public Internet is over.

There are at least 90 projects and businesses today dedicated to building modern private access technologies which allow secure remote connections and access to private networks without opening firewall ports. Many are commercial options serving businesses, but there are also lots of compelling open source offerings for non-commercial use too.

There's a directory of vendors and technologies here https://zerotrustnetworkaccess.info/ which attempts to dispense with some the Zero Trust marketing BS and instead focus on technical discourse, architecture and approach which some might find helpful.

Disclosure; founder of one of the businesses (enclave.io) with a commercial interest in this space.


* Alastair Reynolds - Revelation Space Series

* Dan Simmons - Hyperion Cantos Series

* Martha Wells - The Murderbot Diaries

* Peter F. Hamilton - Void Trilogy

* Liu Cixin - The Three Body Problem (Starts on Earth but goes Interstellar)

* Frank Herbert - Dune

* Joe Haldeman - The Forever War (Earth-based dystopia)


Alastair Reynolds - Galactic North is a fantastic collection of short stories, and his House of Suns is an excellent shorter novel.

He is an astrophysicist, turned, science-fiction writer, and his world building is incredible.


Note for OP: While a big theme in the book is how Earth evolves between war deployments, much of the Forever War takes places elsewhere in the universe


This looks great like a great project. Back in 2017/18 we (https://encalve.io) we're being asked about the possibility merging the network control plane with blockchain. It wasn't one of our design ambitions, but I love that this project introduces Raft consensus to mutate topology. What a fantastic idea for inversion of control from the so-far only centralised model we've seen for the p2p overlay network architecture.


This might be my favourite comment yet on hn :)


Agree with this Adam.

Avery and the team at Tailscale are building a fantastic product and totally deserve the round and recognition, huge congratulations - we're super happy for them.

In many ways they're also an ice-breaker for the zero trust overlay network architecture, which means they've got the most work to do. As the current top comment on this thread correctly notes, with huge investment comes the obligation to eventually pay it back.

The market hasn't even come close yet to crossing the chasm and seeped into mainstream conscience to become the accepted norm - yet.

That said, we believe fiercely that networks should be simple to reason about, easy to use and safe to operate. That private connectivity should “just work”, and just work in exactly the same way, everywhere too. Flexible to change, simple to automate and only available to the right things at the right times.

When you think about it, building private networks is actually pretty complex right now and can be pretty insecure too. It's some unholy combination of spell casting meets a yak shaving contest to wrangle firewalls, VPNs, MTUs, and manage IPs, subnets, ACLs, NSGs, VPCs, NAT, routing, VLANs, certificates & secret keys, then hoping a zero-day doesn't show up that drops someone straight into the network via the VPN server, who then starts poking around the squishy centre.

Once you've used products like Enclave, Tailscale or ZeroTier and seen how simple private networks really can be - at a certain point you almost stop and ask the question, why would you not do it like this.

There will always be nay-sayers and people for whom this approach just isn't a fit, and that's fine - but I personally find it hard to imagine that this genie can be put back in the bottle.

- Founder @ https://enclave.io


What will happen over time is that as we disrupt old-school IT and re-introduce the idea that you can own your own compute (disrupting the everything-cloud model) the various participants in this new area will find niches in which their specific strengths and features shine the most. This always happens. Look at databases. There are like 10 decent sized database vendors for a reason, not to mention several paradigms: SQL, NoSQL, NewSQL, GraphQL, etc.

But if we don't succeed in disrupting the actual competition everyone fails.

At least that's how I look at this market.

Of course I'm also a mostly-follower of the "ignore your market peers, focus on the customer" philosophy. Your greatest competition is always your own shortcomings.


Enclave | Technical Writer / DevRel | REMOTE | Full-time or part-time | https://enclave.io

Computer networks offer refuge for adversaries, absorb tremendous amounts of our time arranging, terminating, and debugging connectivity, are inflexible to change and often actively working against us.

We're funded start-up on a mission to change that. We want to help people build simpler, smarter, and more secure computer networks both at work and at home.

We believe the network should be simple to reason about, easy to use and safe to operate. That means your network should “just work”. It should also just work in exactly the same way, everywhere. It should be flexible to change, simple to automate and only available to the right things at the right times.

Enclave is a new kind of software based Zero Trust Network Access that connects all of your computers, servers, cloud instances, containers and IoT devices together across any infrastructure with secure private networks, regardless of where they are. Whether that's multi-cloud, remote access, collaborating with third parties or just working from home, Enclave gives users predictable, private, and secure connectivity that just works.

We try and make the user experience of building private and secure networks much less complicated. I'm biased as co-founder, but if you're a developer, engineer or DevOps practitioner looking to build secure private networks and precision access without having to do anything complicated whatsoever, Enclave might be the answer. Users enrol systems, tag them, and then build policy out of those tags to define who can talk to what. It's super simple to get started, with no ACLs to setup or firewalls ports to open.

We're looking for experienced Technical / DevRel writers who can help us explain all of that and create great conversations with our technical users and are looking for someone who can support our efforts to build, develop and grow engagement across our channels. The content you produce will be used on our blog, website, emails, and social media and you’ll be helping to evolve our company voice and build communities and customer awareness.

You can read the full job description here https://enclave.io/careers/technical-author/ and check our docs here https://docs.enclave.io/

If you'd like to apply, please email people AT enclave.io to introduce yourself with your CV attached


Enclave Networks | C# developer | London, UK or REMOTE (Europe) | Full-time (EU time zones) | https://enclave.io

We are an early stage funded start-up (see https://enclave.io/enclave-has-launched for our story) with a mission to help people build simpler, smarter, and more secure computer networks both at work and at home.

Enclave is a networking technology which just works. Without listening ports, visible IP addresses or DNS records, your infrastructure goes dark to attackers allowing you to quickly build secure and private connectivity between any application, computer system, device, or infrastructure — regardless of the underlying network.

We are looking for talented C# developers who treat code as craft, understand computer security concepts and have experience working with network protocols and systems level programming to help us continue to design, build and scale Enclave and our SaaS platform. This is a key role working as part of a scrappy team of passionate developers making a big impact with few resources and reporting directly to the CTO.

Our stack is primarily C# .NET Core 3.1 but you’ll also be working with cloud infrastructure, network protocols, cryptography and systems level programming across Windows, Linux and Mac OS and mobile platforms so you’ll need a willingness to learn and a desire to tackle hard problems.

You can read the full job description here: https://enclave.io/careers/senior-csharp-developer or introduce yourself with your CV attached to people AT enclave.io


There is a minor issue in your quick start guide with this sentence: "In order to use Enclave, your system will a certificate, and license keys enable Enclave to request certificates."


Good spot. Thank you for taking the time to point that out, much appreciated :)


Happy to help. I spot these things almost everywhere I look, it is both a blessing and a curse :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: