> zrok provides Private or Public, instant, secure tunneling of applications from anywhere.
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.
It's more peer to peer file sharing and web content sharing than truly distributed sharig but with a globally available service, it's "distributed" ina way. It's not doing sharding or anything fancy like that (yet anyway). Right now, it's a dev-focused tool similar to the other projects out there like ngrok/tailscale funnels/cloudflare tunnels etc. There's a fair number of them now-a-days. :) But it doesn't need to stay that way and might change.
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.
On surface it looks similar to ngrok. Except you can self host this using the open source project openziti that support the infra for it. It seems to be either a wrapper or implemented using openziti
In this video from 11 months ago, at 25 min. they say this:
“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.
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.
Trying to keep it short, I would say OpenZiti is similar to zerotier moreso than zrok. This zrok tool though is closer to ngrok. I mentioned that in another comment so hopefully that's easy enough to find in the page.
It says it uses an over-lay network? If the topology is just like:
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.
While OpenZiti can do P2P connections, having a overlay in between gives you many advantages incl. outbound connections at source/destination to circumvent NAT/port forward/inbound ports etc.
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).
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?
> 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.
Great question. I am in the process of creating some public documentation for the OpenZiti project vs [insert tech]. OpenZiti is more akin to Wireguard (i.e., open source), CloudZiti is more comparable to Tailscale (hosted SaaS)
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!
We keep working on actual benchmarking but it's somewhat tricky to get reliable numbers... We're working on it now. Sometimes it's 'favorable' sometimes it's not. That's kind of a non-committal answer from me, but that's the best I've got for you at this time.
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
I am a dev on the OpenZiti project. I personally think Tailscale is more similar to OpenZiti. It's making wireguard administration really easy.
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).
I just looked up ngrok right now and it looks really cool, but I wonder what people actually use it for? Are people actually running production software this way, or is it just for sharing e.g. demos with coworkers? If the latter, it seems to me like a narrow use case that can already be served by automated devops stuff.
Again this is new to me, so I'm probably missing some obvious use cases. Do you use it for anything in particular?
- 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
Easily sharing local resources is a common need as a dev, for sure. If I'm making changes to a web form, updating online doc, etc. it's dreadfully convenient to just share that resource for some short amount of time...
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
This is the thing. I used it for debugging stripe and AWS SNS webhooks a bunch last year.
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.
yes, zrok is open source and tailscale is not. zrok has a private share mode in which you share the resource without any internet exposure (not even temporary) - nice for security and cases where you need 2 or more private enviros (rfc 1918 space) to talk w/o opening any ports.
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.
Seems interesting, but I think it needs some use case examples to show how it differentiates from a tunnel, VPN etc.
As an example, would it be the right tool to access IoT data from small sensors (and actuators, therefore two ways) in a private LAN from external machines, including mobile, on untrusted public networks?
Or what if I wanted on all my laptops a shared directory that replicated on all machines what is being written on one, no matter which networks they're connected to, NAT etc.
etc...
I said somewhere else in the comments I was working with a fella and he shared his vault instance with me via ngrok (zrok didn't exist at the time). So ngrok/zrok are great, dev-focused tools (p2p). (zrok might grow past being a great dev/p2p-focused tool too)
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
The file sharing part of this project made me think of RetroShare (https://retroshare.cc/). Too bad this project never really had traction. It was really file sharing + social network in a truly decentralized fashion.
Very interesting product! How does this compare to something like Nebula? Have you done benchmarks against other solutions? If i remember correctly, Nebula implements its own protocol and underperforms compared to Wireguard. Is this the same case?
I am writing some comparisons to other tech incl. Nebula, its not publicly published yet, but I can give a few bullets. WRT to performance, better to compare OpenZiti to Nebula rather than zrok, we did some last year - https://netfoundry.io/benchmark/benchmarking%20open%20source....
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.
What does "zero trust" mean in this context? I assume the network isn't trusted, but is anything else trusted? How are peers authenticated and/or authorized to access a zrok end-point?
There's always a "root" of trust somewhere/somehow. Ideally it's a human that you trust. In the case of zrok, it uses a secure zero trust overlay provided by openziti. you "enabling" zrok in your shell is that root of trust. you get a x509 certificate which is then used to attach to the zero trust overlay. On the other side when you "zrok access" you provide a unique token that has been shared with you by someone you trust (presumably). So you, as the person doing the sharing are the real "root" of the trust. You're trusting that zrok isn't compromised and that the certificate that is returned to you from the overlay is trustworthy etc. I could go on - but that's hopefully enough of an overview
Yes that's exactly correct. The underpinning of zrok is an OpenZiti overlay network. That network relies on a fabric of routers all meshed together. (self hosters would probably have _one_ router, but you get the point).
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)
I hope a GUI will emerge from this, enabling the comfortable, the less knowledgeable and the less technical to avoid fiddling with terminal commands and all that.
We had this question in another thread so I will copy paste the answer :)
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.
I wouldn't think so tbh. Unless whatever editor you're using is sharing a web resource... In that case, sure. If you need/want UDP/TCP type sharing you could use the underlying OpenZiti overlay network for that, but out of the gate, at this time I don't think it'd support most "P2P editing". zrok certainly doesn't provide that type of functionality at this time
Not at this time. Right now zrok is for web (http) and file sharing. It's possible that sharing other UDP/TCP type sharing could be added in the future. Right now the overlay network (OpenZiti) would be able to support that right now if you were looking for any TCP/UDP.
zrok.io is more comparable to Tailscale Funnel. Lets break this down :)
- 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:
Do you mean Hamachi? Hamachi is a VPN capable of establishing direct links between computers that are behind network address translation (NAT) firewalls without requiring reconfiguration.
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.
How is NKN different from, like, the internet? Nothing on the homepage tells me why there is a blockchain involved. Nothing it talks about cannot be done with TCP/TLS/etc etc.
If it's a p2p framework then something like libp2p, holochain, or p2panda would be much more appropriate than a blockchain with "incentivized miners" (incentivized to do what??).
I think the reason people are reinventing the wheel is because blockchain tech has extremely limited use-cases and all the people who tried (or are trying) to use it outside of its applicable domain are misguided, prompting further exploration into the p2p space that isn't tethered (no pun intended) to a global state that has to be shared by every node in the system which is an inherently unscalable solution for anything beyond a handful of performant nodes (ie, sharing transactions between banks or something).
to route traffic. NKN is a CHORD overlay on top of the internet. clients connect to nodes and nodes route traffic from one node to another until the packet reaches its destination. clients stay anonymous (no IP leakage). end-to-end encrypted communication. "Proof-of-Relay" algorithm for mining. consensus via MOCA.
the only state of the art blockchain technology I know of. and they dont even pay me to say this.
The purpose of the shared project has nothing to do with nkn, either in usage or ahem a blockchain.
The shared project is more of a p2p VPN to access remote services privately, as opposed to a VPN for accessing the broader internet. Yes, there are other services that do something similar to Zrok, but this actually builds on one (openZiti) presumably to handle the connections more abstractly (and also presumably to launch their own paid SaaS endpoint?). I could see this more competing with Tailscale to access Internal tools at a company, or for home-lab users who want to access/share services they're running remotely.
Is this decentralized file sharing?