Openziti eliminates routing tables, IP addresses, and so many other things.
However, it is also conceptually complex, and for a small setup, it doesn't seem worth the effort it takes to properly learn and set it up.
For a small home setup that I want to access remotely, a traditional VPN like ipsec or openvpn seems easier.
Is openziti still useful for a small personal network?
Hi @amano, welcome to the community and to OpenZiti (and zrok/BrowZer)!
I'll start with this... I sure think so! It definitely does all the things you mentioned and it also has SDKs for devs to integrate. Also zrok is super cool and allows you to quickly share things publicly with ease and is based on OpenZiti for secure connectivity.
It's different, that's for sure. It also introduces new concepts and that ends up making it be more. I entirely agree. I was just chatting with a colleague the other day about this. To us, this stuff is all "easy", but we do it every day (and have for years). Anything you do that much becomes easy.
I think it's worth it if you care to have the very best in zero trust security and are interested in any of the features it offers. I also think it can feel overwhelming because the project accomplishes so much.
Would you find a quick video useful? Or are you more of a "I like to read" sorta person? We have a lot of great blogs that I could point you at or maybe a video or two if you like. 
And I'm (we are) always here to help you with understanding, if you have questions.
I'm not 
, but I'm "pretty sure" that certs are not managed in the database. An enrolling identity will bootstrap trust, make a CSR, and send it to the controller to sign using the configured signing CA and send it back to the client. The fingerprint is maintained and mapped to the identity in the bbolt db.
The config is all stored and sourced from a bbolt db colocated with the controller. (this changes with the new HA stuff where the 'model' will be stored in a raft cluster)
Updating/affecting the db can be done using the OpenZiti CLI which you can use for scripting. OpenZiti is fully automatable via an API, if you prefer to go that route and a new PR just came in this week for using a declarative type of approach which would allow you to maintain a text file and then import/export it from the controller (this PR isn't merged yet).
Yes. Assuming you allow OpenZiti to generate the certs, it'll control rotating them accordingly. This gets more complex with clients. The default policy of OpenZiti is to NOT verify a cert's expiration date just because lots of things that go offline for extended amounts of time might not be able to join / renew their certs. You can control that via an auth-policy if you choose.
So, the certificate fingerprint is stored in the controller's bbolt db.
That's one I'm not well-positioned to answer. I'm more "the windows fella" on the team, so I am not as familar with linux. I know how to do "most things" but getting into the weeds with the resolvers isn't something I've done all that much. I do know we talked about this just this week.
@ekoby / @scareything, did anything end up getting decided wrt systemd and modifying /etc/resolve.conf? I felt like when the conversation ended, it felt like more discussion was needed?
Routers 'advertise' addresses. If they are configured with an "edge listener", the information is distributed to the client when it authenticates to the controller
Example of an edge listener on a router along with allowing the router to work as a tunneler to offload data from the OpenZiti overlay to the IP-based underlay:
listeners:
- binding: edge
address: tls:0.0.0.0:8442
options:
advertise: ec2-3-18-113-172.us-east-2.compute.amazonaws.com:8442
connectTimeoutMs: 5000
getSessionTimeout: 60
- binding: tunnel
options:
mode: host
I assume you are referring to an OpenZiti router, you just turn them on and make sure clients can connect to them and they will use them.
Nothing. We have been using edge routers for everythign for a long time. There used to be "fabric only" routers (and you can still use them), I don't recommend them. If you want a router that doesn't participate in the edge and is "fabric only" -- you can just remove the edge listener (the thing shown above) and then the router will only participate in the mesh overlay network
Do you mean an openziti router advertises itself at the link level on a LAN? And, openziti tunnel will find a router through LAN advertisements?
Perhaps, a public router can be automatically linked with a private router if I host both on the same machine or the same LAN segment?
I still don't understand how public openziti routers hosted by commmercial providers are found. Are the addresses of commmercial public routers hard-coded in router software? Or?
As far as I know, there are only several ways.
No. When an OpenZiti client authenticates to the controller, the controller will inform the client what routers are available and the client will establish 3 (by default) connections to routers. It not link-level.
Yes and no... When you bring the private router online, it'll do what you inform it to do. So if you bring that private router up without a "link dialer", it will NEVER try to connect to another router as it has no "link dialers".
If you configure the public router with no link listener - then the private router even if it has a dialer won't ever form a link because the public router has no listener.
So you need to specifically configure a router with link listeners, or link dialers (or both)... Assuming you configure both, then they will "automagically" form a link/mesh because the routers advertise these links to the other members of the overlay, through OpenZiti itself.
I think that also answers the last question with respect to finding routers? The routers must be authorized to connect to the controller (via the enrollment process) in order to learn what routers are available. Then the routers decide if they are listeners/linkers or both.
So, everything else only needs to know how to find the controller address?
Whether they be controllers, routers, or endpoints, they all need to be able to connect to the controller, yes.
This information is embedded into the JWTs (single use tokens) so when you share a JWT with someone, they don't even need to know that (the controller address). You email them a jwt and say "enroll this identity" and they don't need to know anything really - other than you are trustworthy and they trust you and the subsequent JWT you're sending them.
I think I get how it is all wired up. I will just wait for answers on /etc/resolv.conf, systemd, tproxy, and tun.
There are a few tunnelers that run on Linux.
systemd-resolved is not active on the host. The edit may fail due to permissions, in which case it continues to run with its internal name server enabled, so if you have set up the resolver to use the ziti-edge-tunnel name server for ziti hostnames then they will resolve. Note that most resolv.conf resolver only uses one of its known name servers at a time, cycling to the next one only when a connection error occurs. Because of this, if you're using ziti-edge-tunnel as your name server in resolv.conf then you'll very likely want to run ziti-edge-tunnel with the --dns-upstream option to let it know where to send requests for hostnames that are not associated with your ziti services.ziti-edge-tunnel it always runs an internal name server that can be accessed at 127.0.0.1:53 by default (this can be changed with the --resolver command line option), so if you point your host's resolver at this address then the ziti hostnames will resolve.There are tradeoffs to each of the intercept techniques. The advantage of tproxy (which is only available when using ziti router) is that it uses the tcp/ip stack in the Linux kernel, which is very robust and performs relatively well.
The only way to intercept with a tun device is by using ziti-edge-tunnel. ziti-edge-tunnel uses lwip for its tcp/ip stack. lwip is geared towards having a small-ish memory footprint, but it achieves less throughput than you'll see when using tproxy
I thought tunneler can use tproxy?
It's exclusively an edge-router running in tproxy mode.
Okay, ziti/ziti-tunnel at main · openziti/ziti · GitHub is outdated. Options and Modes | OpenZiti is correct.
the standalone, go-based tunneler, ziti-tunnel, has been deprecated for a while, correct. It is replaced with ziti-edge-tunnel. The edge-router is the only tunneling software that is expected to be maintained and use tproxy at this time and it is possible it may change as well.
Other operating systems have GUI tunnelers. Linux tunneling situations is being reworked?
At this time, the work on a linux-based UI has been paused. It will start up again at some point in the future.