Zrok: Open-source peer to peer
zrok.io
zrok.io
Is this decentralized file sharing?
This one is built on top of OpenZiti (I am a dev on that project) which is a secure, zero trust overlay network. It's fully self-hostable and open source which some people find attractive. The hosted version our company is sponsoring for free (at least 'for now').
The key goal is to make it super easy and safe to share files/web content.
“Ziti is only providing a pipe. That’s also very important. Some people might think that there is more going on there, but Ziti is literally, just… just a black hole, from one side to the other, and how it gets there… it’s like an SSH tunnel.
https://www.youtube.com/watch?v=qyjM5y8Op_I&t=1509s
He goes on to say “I’m going say it publicly: my mission is to kill REST. […] I’m going to bring us all the way back to the 1990s, and we’re going to do RPC all over again”
The linked article is about Zrok, which seems to be an application on top of that OpenZiti overlay network on top of the Internet.
Its a tunneling tool, to share a port/etc from one computer to another. You can connect to a computer, even if you don't directly have a route to it's IP.
> Secured effortlessly by using a zero trust overlay network provided by OpenZiti
It uses OpenZiti to accomplish the links, as opposed to tailscale, zero tier, cloudflare tunnels, Yggdrasil, etc.
> zrok allows sharing other types of resources; rather than just proxying http endpoints, zrok allows users to easily and rapidly share files and web content. zrok is also ready to be extended to easily support many kinds of decentralized resource sharing; zrok provides a framework that makes this kind of peer-to-peer resource sharing simple and secure
It looks like its also extensible, so you can use it to form the communication layer to share other things, files being one example.
peer A <---> overlay (server N ...) <---> Peer B
And your design is to try get packets between the peers then this is going to be very slow. They will have to go via the routes on the overlay network which may have multiple virtual hops to reach their destination. This is a massive increase in round trip time. I'm not sure if I understand the solution right though as I took a brief look. But I don't see how this solves port forwarding or NAT issues as the actual instances still need to be publicly reachable.
I wrote a library for peer-to-peer networking recently and unlike libraries like Libp2p -- my emphasis was on getting direct connectivity to work between peers. I'm not using an overlay for this. I use a range of techniques [direct cons, reverse con, tcp hole punching, TURN] to make the connections happens. With some minor signalling traffic happening over public MQTT servers.
My software is at https://github.com/robertsdotpm/p2pd if anyone finds it interesting. Sorry for the shameless self-plug but I figure it is related. We're both free open source projects. I don't provide a tunnelling solution but you could easily build something like ngrok with this software without relying on proxying as the primary solution. Currently the software has no way to easily get another peers 'address' so using this will need to solve that problem. But a simple key-value store would be enough tbh. Going to improve usability when I next have time.
What's cool about it is that we built the overlay to do smart routing so it calculates the lowest latency paths and rebuilds, thus, as you have more nodes, you have the ability to actually circumvent BGP and deliver lower latency.
We welcome the shameless plug, everything open source is our friend! zrok solves the peer address issue by providing the reverse proxy so that you can share a URL for public share or endpoint and URL for fully private share.
> In the discussions about v0.2, the (now obvious) idea came up to implement something that we're calling "private sharing". It works a lot like the traditional on-demand reverse proxy, except instead of exposing the private endpoint through a public HTTP listener, it binds the shared resource onto an OpenZiti network, where it can be accessed securely by another zrok client. This "other" zrok client exposes an HTTP listener wherever the user wants... but it's usually put on the loopback interface of that user's system. This allows the user to securely access the shared resource on their system as if it's local, even though it's somewhere else on a zero-trust network.
> As we've started working through the development of v0.3, we've realized that we can incorporate other useful capabilities, like streamlined file sharing (elegant WebDAV integration is coming).
From a quick look, it seems that the self-hostable part (https://github.com/openziti/zrok/blob/main/docs/guides/v0.3_...) is written in Go, and there are SDKs for connecting to it from a variety of languages.
Oracle has an article on the underlying network layer which is called OpenZiti, which defines ZeroTrust:
> Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.
All of this sounds very interesting to me, but I have no experience with these kinds of network stacks. Has anyone here evaluated it?
Would this be useful for adding document sharing to applications I write, for instance, a hypothetical word processor? I mean sharing with other people working on a document. The SDKs seem to be clients, so to interchange files between two applications with an embedded SDK, does it still need a third machine running an API server?
We could certainly incorporate an "embeddable" SDK so that zrok can be incorporated into other applications.
As it currently stands, you would need access to a zrok "service instance" ("cloud"), running the zrok controller (providing API access). But we could certainly look at other kinds of use cases where that control plane is potentially enabled ephemerally or on-demand. I have some ideas for things we might be able to do.
Neither of these are on the immediate roadmap. But if people ask for them, we could certainly build them.
zrok is very clearly based heavily on inspiration from the amazing tool called ngrok. If you haven't checked them out you should. They are widely loved for lots of good reasons. Other product/projects in this category is Tailscale's funnels or Cloudflare tunnels.
Key differences to ngrok are it being fully open source and fully self hostable. zrok allows you to do public/anonymous type sharing too but also has this private sharing feature that you might find neat. Basically it'll hide your app behind two "localhost" type proxies all transparently (to most people).
Again this is new to me, so I'm probably missing some obvious use cases. Do you use it for anything in particular?
I've used similar tech when collaborating with a fella recently, he stood up a vault server and I hit his private API over an ngrok share because that was the tool he had used, liked and was familiar with.
It's just super handy to do that sort of thing when/as you need to
- showing a POC running locally / quick demo/ short terms project
- debug incoming webhook or the like. Let’s say you have a service where you can register a URL, and that the service will post a http request to you when a event occurs.
I use ngrok, piped to a local handler. It’s convenient
However, ngrok totally lost its soul in the past few years. It looks like the pricing was lowered again recently, but for a while there they had no “personal” or ~indie priced plan.
Meanwhile they did a feature takeaway from annual subscribers, and a less than good transition of those plans to their new system and pricing tiers.
If you go to ngrok.com right now there is a big header banner that reads: “ Announcing 50M round for API-first ingress-as-a-service. ”
This service used to be run by maybe one or two people. I could not be less interested in a developer tool that treats VC funding as something I should be excited about. The product was good the way it was.
I’m glad whoever was involved seems to have found an exit of some kind—-but all that is to say zrok looks great. I won’t renew my ngrok sub, and will go through the trouble of updating the saved dev testing URLs at stripe and AWS.
Here are some shorted bullets vs Wireguard (with references to Tailscale).
- Rather than connecting machines, Ziti cares about connecting "services" with zero trust networking concepts. This can be surmised as Wireguard being 'default-open' whereas ZT is 'default-closed'. Wireguard is normally combined with a firewall to deliver ACLs and network segmentation controls.
- Whereas WireGuard securely encapsulates IP packets over UDP and uses hole punching, OpenZiti uses TCP and a mesh overlay (with the outbound only at source and destination). This is how Tailscale implements Wireguard to ensure it works easily in all situations. All of this is open-source and native to OpenZiti, not in Wireguard.
- Due to OpenZiti's uses of identity in the endpoints and fabric for routing, you also get private DNS, unique naming and outbound connections. No need to use floating or static IPs, easily handle overlapping, and have no need for port forwarding or NAT issues.
- While with OpenZiti you can start with "network-based zero trust" (installing a router in private IP space) and progress to "host-based zero trust" (using an agent/tunneller); it also has a suite of SDKs to embed in apps themselves for "application-based zero trust".
P.S., OpenZiti uses the Windows TUN (WinTun) that the Wireguard project made as (at least) part of our Windows tunneler. Thanks, Wireguard!
I'd expect wireguard to often be faster due to its protocol/implementation. I've seen people complain about wireguard if you don't set the MTU. Maybe you'll try them both out and blog about it??? :) (that'd be pretty cool regardless of the outcome tbh).
What I usually tell people, is that I use OpenZiti/zrok all the time. As a human, I don't even notice it. Sorry we don't have better details at this time but hopefully that a reasonable answer
if your question was centered on the compare between wireguard and openziti. both are open source network overlay solutions and both have large scale saas options (e.g. cloudziti from netfoundry; tailscale for wireguard).
4 key differences between openziti vs wireguard are (1) app vs. device; (2) p2p tunnel vs full mesh; (3) management model; (4) security model. it mainly comes down to what your use case needs and doesn't need.
(1) app vs. device the atom of wireguard is a device. the atom of openziti is an app. devs embed openziti directly into the process space of an app or api as code (using openziti sdks) such that installing your app spins up a zero trust overlay for your app w/o distributing agents. alternatively you can use openziti agents for mobile, desktop, cloud edge, etc. in that model, the agents are still app-specific, e.g. only services you specify go on the overlay; rest are ignored.
(2) vpn vs. sdn like mesh wireguard gives you p2p tunnels like most vpns. openziti gives you control of a full mesh, latency optimized network - like a programmable sdn. if you want x connections from a given machine (e.g. an api to cloud1, a different service to cloud2, some other app to cloud3) then openziti is designed to make that simple for you. if you want a single device level tunnel for all data, then wg may be for you.
(3) management model with wg, you manage certs, p2p tunnels, restrictions/ACLs (tailscale etc help you with much of this but then you are buying a closed source product). openziti builds all this into the foss for you. you even control the full mesh fabric (programmable ziti routers) listed above. so wg may be simpler if you have a limited # of endpoints, routes and restrictions to manage.
(4) security and compliance model openziti provides mTLS, X.509 based identities, private DNS, e2e encryption all the way to the process space of the app (see item #1 above), default least privileged access, mfa, posture checks, etc. that is overkill for some uses - it does carry some complexity with it - wireguard may be a better choice for those cases.
For what you're describing, the OpenZiti overlay might be more your ball of wax. It's a bit more complex than just "share" this and "access" that so there's more to learn (which is why ngrok/zrok are so nice, they are *EASY* to use) but you might find value in the tech that is under zrok, that OpenZiti overlay
AFAIK it is still maintained.
Looking forward to trying it out!
A few points of comparison:
- Nebula is focused on connecting machines, OpenZiti is on securing services. This is due to Ziti implementing zero trust networking principles – e.g., you can authorize only a single port without needing to set up ACLs or firewall rules.
- While Nebula requires open inbound ports or UDP hole punching, OpenZiti allows you to have all inbound and most outbound ports completely closed while providing truly private, zero trust DNS entries with unique naming – if you wanted to call your service "my.secret.service" you can do that, it does not force you to have a valid Top Level Domain.
- OpenZiti also goes a layer deeper to bring zero trust principles directly into your application. If you're a developer, you can embed all those ideas into your app and not rely on the network or side-loaded agents. This is both client and server-side and doesn't require the app to "listen" on an IP address (the underlay). Instead, you can choose to "listen" on the overlay.
Sounds like there’s a central server to coordinate and transmit piped data.
If so, does the central server have to transmit all data?
Both ends attach to the overlay, then the overlay mesh fabric is responsible for getting traffic from one place to the other securely in a zero trust way (you can read about OpenZiti if you want but I think you 'get it' already, but let us know if you have other questions)
Yes! We're currently targeting an end-user UI for v0.5. My crystal ball is imperfect with regards to timing, so don't hold me to it... but I would imagine that this will probably come out sometime in the summer.
https://github.com/openziti/zrok/issues/221
And I would imagine some sort of mobile-first interface would happen after that.
- Tailscale Funnel is their feature to allow you to route traffic from the wider internet to one or more of your Tailscale nodes (public sharing). It is closed source SaaS. Tailscale is a SaaS built on open source wireguard.
- zrok.io is a SaaS for public or private sharing of content, files, websites, webhooks etc. It is built on top of zrok, an open source 'ziti-native' app. It is built on top of OpenZiti which is also open source. If you want SaaS, then we have CloudZiti.
To the 2nd part, 100%. Wireguard (and thus Tailscale) is focused on connecting computers as default-open. Ziti connects services, default-closed, without the need for firewalls, ACLs etc.
Myself and another wrote deeper comparisons on this thread so I will just link there:
- https://news.ycombinator.com/reply?id=34713131&goto=item%3Fi...
- https://news.ycombinator.com/reply?id=34714123&goto=item%3Fi...
zrok is a reverse proxy to easily share resources (http, files, web content) via a public URL or private share. zrok is built on top of OpenZiti.
OpenZiti is more comparable to Hamachi but being open source, more powerful and modern.