Hello @sadath-12. Welcome to the OpenZiti community.
That sounds like a good use of Ziti.
You got the controller and router charts installed, and you followed the first service tutorial to also install the hello-toy chart as a web server target for the Ziti service.
Now you should have a client identity with dial permission for the hello service that's hosted by the router identity.
Let's verify everything is set correctly with the policy advisor command from the first service tutorial that you followed.
then what I did was I ran the tunnel via docker Containers | OpenZiti in my mac and then got an error
ERROR tunnel-cbs:ziti_dns.c:117 next_ipv4() DNS ip pool exhausted (0 IPs). Try rerunning with larger DNS range.
I discovered your twitch tutorial and followed that , the difference was my system was mac and I ran the tunnel via docker but you had tunnel service in your linux
I see! You need the macOS tunneler, not Docker, to use a Ziti identity as a client on macOS: Downloads | OpenZiti
Add another client identity with the same role, #hello-clients to the macOS tunneler and then you can access the hello service from macOS.
It's because Docker containers are a feature of Linux, so they run in a Linux VM on macOS and Windows, and cannot configure the non-Linux host's DNS or IP routes for the proxy.
Side note: I suspect the zero IP addresses message may be a misleading error that occurs when the tunneler is running as a reverse proxy (run-host mode) which never uses any intercept IPs.
I get the same error when I ran the docker tunneler in latest ubuntu machine in aws and then on that same machine when I ran linux tunneler it was working
@sadath-12 I think you are clarifying that you have not tried the macOS tunneler named "Ziti Desktop Edge for macOS" for your client proxy. You did try the Linux tunneler running natively on Linux successfully and the Linux tunneler running in Docker unsuccessfully.
I'm glad you were able to use the Linux tunneler (ziti-edge-tunnel) natively on Linux!
It is possible, but not typical, to use the Linux tunneler in Docker to provide a client proxy. Here is the documentation for that use case: Containers | OpenZiti. It's essential to grant privileged mode to the container and mount the necessary files so the container is able to configure the Docker host to provide IP routes and Ziti DNS to the Docker host. I don't feel confident this is best, however. It's a little complicated when compared with installing the Linux package natively on the Docker host.
It is also possible for a Ziti container to function as a client proxy for another container. This is best accomplished with the router container. Here is an example.
1- lets say I gave an employee an indentity to access my service in his machine for tunneling and he resigns , how do i revoke his access from my machine
2 - For new routers to register is knowing the controller ip the only thing stopping them to connect ? How to secure connecting to controllers in more secure way
You may revoke access by deleting the identity or adjusting the service policy. Service policies grant identities access to services. For example, if the identity has a role #bookkeepers and the service policy grants this role, then access can be revoked by removing this role from the identity.
The controller provides public APIs to identities and routers and must be reachable from anywhere on the controller's advertised address (FQDN).
I meant that you may administratively delete the identity from the Ziti controller. The controller's management API is typically used through the web console or CLI.