Zrok: Open-source peer to peer(zrok.io)
zrok.io
Zrok: Open-source peer to peer
https://zrok.io/
67 comments
> 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.
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.
this was an awesome, non-snarky, explanatory comment. thanks for this.
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.
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
It seems to me that is some kind of tunnel/vpn a-la-zerotier?
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.
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.
“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.
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.
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.
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.
It's a cool idea. I do see the use-cases for it. What you said about BGP is also interesting.
Always happy to see more open source options in this space. I maintain a list of similar tools (including OpenZiti) here:
https://github.com/anderspitman/awesome-tunneling
https://github.com/anderspitman/awesome-tunneling
I put a PR up for zrok... :)
https://github.com/anderspitman/awesome-tunneling/pull/82
https://github.com/anderspitman/awesome-tunneling/pull/82
Nice work on maintaining that by the way! Can we get zrok added to the list of 'Open source (at least with a reasonably permissive license)'??
There was a post one day ago, apparently from the creator of Zrok, giving more context on this: https://news.ycombinator.com/item?id=34693988
> 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?
> 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?
> 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.
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.
How does this compare to Tailscale, beyond being based on OpenZiti instead of Wireguard?
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!
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!
Thanks for this. How does speed of OpenZiti compare to Wireguard on network on same LAN? Eg. if you connect machines on same VPC?
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'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).
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?
Again this is new to me, so I'm probably missing some obvious use cases. Do you use it for anything in particular?
I often use it for :
- 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
- 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
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
I found ngrok looking for simple and safe ways to share our local minecraft server among my kid's friends. (about 5 years ago)
Consuming webhooks in dev environment is one use-case.
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.
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.
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.
Also curious how it compares to https://github.com/holepunchto
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
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
I doubt Activision cares, but what does this have to do with Infocom and Z-machine?
man, those were the days. I actually played it on my Atari 800
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.
Retroshare may not be viable as a worlwide social network but it is definitely useful for smaller circles, families, etc.
AFAIK it is still maintained.
AFAIK it is still maintained.
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?
Looking forward to trying it out!
Looking forward to trying it out!
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.
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
Thanks; that's exactly the ELI5 I was looking for.
Along those lines, I wrote a blog on how I described my job and zero trust to my daughter (who is 5) by using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...
[deleted]
How is this establish a route to an IP that cannot be routed directly to?
Sounds like there’s a central server to coordinate and transmit piped data.
If so, does the central server have to transmit all data?
Sounds like there’s a central server to coordinate and transmit piped data.
If so, does the central server have to transmit all data?
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)
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.
https://github.com/openziti/zrok/issues/221
And I would imagine some sort of mobile-first interface would happen after that.
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.
I did not expect anyone to answer my comment, so many thanks for that. I actually look forward to the UI.
Can this be used for a P2P pair editing session?
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
maybe it could be used to share a tmux session? (which is my favourite way for collaborative editing)
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.
So is it like Tailscale (amazing btw) but, instead of secure connecting computers, I can secure connect services?
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:
- https://news.ycombinator.com/reply?id=34713131&goto=item%3Fi...
- https://news.ycombinator.com/reply?id=34714123&goto=item%3Fi...
- 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...
So it’s like cloudflared or localtunnel?
Similar yes. Open source and self hostable are notable differences, but yep.
Okay, after reading the homepage of OpenZiti, now I have a zero-trust-phobia.
Is this hitatchi
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.
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.
[deleted]
omani(3)
Is this decentralized file sharing?