Hello,
I am working on this project where i am having multiple mqtt gateways which is having brokers installed in it. I would need to access the broker remotely to control the devices in the network. Is it possible to acheive this using openziti? if acheivable will each local broker have seperate url to access??pls help
You want to public TCP share and it is possible if you self-host a zrok access frontend on a public IP.
This is too broad of a question to answer succinctly. The broad answer is "yes". @qrkourier has highlighted one way to do it, but there are many, many ways to accomplish this. Yes you could use openziti. Yes each broker can have it's own url/intercept, you could do it with ports as differentiators...
At the end of the day -- definitely possible with zrok or with ziti and possible in numerous different ways. If you're trying to use zrok.io so that you don't have to setup anything on your own, the only option there is to use a private tcp tunnel... but the answer is still 'yes'. 
is there any tutorial or steps to follow or just exposing the local ip is enough?
thank you @TheLumberjack @qrkourier for the responses
Are you going to self-host your own OpenZiti overlay and/or your own zrok instance? Are you trying to accomplish this using the NaaS zrok.io?
Need to know your plans to be able to answer.
yes i am planning to self host zrok instance. Now i am trying to simulate this setup using raspberry pi as server and custom board as client which is having the mqtt broker. which is okay to do right??
"Custom board and client" -- are you developing an app? If that's the case, I would very strongly urge you to consider building OpenZiti into your app. That way, you don't need a separate client on that board (meaning a 'tunneler'). If you're planning to go that route already - awesome!
Still need a bit more detail to be honest. After learning more, it sounds like you'd possibly be better off using "just" OpenZiti. Who will be accessing the mqtt broker and 'how'? Also custom software? If so, you could build OpenZiti into that software too and then you'd really only need OpenZiti (not zrok).
Sorry to keep asking questions, but do you have a diagram of what you're tyring to do? Understanding what you're up to just helps me give you the 'best' information.
Thanks for the diagram. The mobile app -- are you/your company responsible for developing the app? Are you considering adding an SDK into the app itself or are you just users of an app you don't have access to change?
Same question for the far side from the mobile app. is the MQTT gateway at the remote location software you/your company develops?
The broker is at our location as we are developing it. The diagram is explained for both use cases if the user is at home or outside home as in home automation.
The app is being developed by another company so we can ask them to include the SDK . It will be better if no components are added in the app because the project is now way out of budget
Gotcha, now I understand better what you're trying to do. Given the statement wrt the app's budget, it makes more sense why you'd want to use a public url and why zrok has come into the equation. The MQTT connections -- are they TCP/TLS or are they websocket based or are they UDP?
If you're using websockets - I think zrok would be a great fit. If you're using raw TCP/UDP, I think zrok isn't as good of a fit and I'd probably end up using OpenZiti
Don't know that I would agree with that. You can easily expose TCP or UDP to the public internet using zrok. Here's a short video that illustrates the general concept... Would apply if you're self-hosting zrok, or using the global instance.
MQTT is TCP/TLS i think zrok will be a fit right?
Yes. You can put a zrok access private anywhere on the internet to expose a port for your MQTT broker. You could also put a zrok access private on your end nodes, and allow them to access MQTT without ever traversing the public internet, for full zero-trust.
The tcpTunnel backend mode will work for MQTT.
i have successfully connected my environment running in a local device to a self hosted server using zrok. Now i am trying to expose mqtt port as you mentioned above.
using zrok share private --backend-mode tcpTunnel 192.168.1.12:1883
i am getting error
[ERROR]: unable to create share (error getting zrok client: error getting version from api endpoint 'http://raspi.local:18080': Get "http://raspi.local:18080/api/v1/version": dial tcp: lookup raspi.local: no such host: Get "http://raspi.local:18080/api/v1/version": dial tcp: lookup raspi.local: no such host) do i need to make any modifications in server or client side???
@TheLumberjack @michael.quigley @qrkourier
FYI - you don't need to tag us. It looks to me that you're trying to use your own locally deployed zrok environment. i assume your zrok endpoint api is set to http://raspi.local:18080 purposefully? Assuming yes, the error is clear - where you are running zrok from cannot access raspi.local.
I don't know what you're doing, or how but that's the problem with running zrok share. The zrok binary will necessary need to be able to access the zrok api.
oh sorry for that. zrok endpoint should be the address of the local machine which i am running the environment not the zrok server instance's address am i correct ?.
raspi.local is the address of the raspberry pi that i used to selfhost zrok (for testing)
now i cant disable the zrok environment gives the same error
[ERROR]: error creating tcpTunnel backend (error listening: failed to listen: no apiSession, authentication attempt failed: Post "https://raspi.local:1280/edge/client/v1/authenticate?method=cert": dial tcp: lookup raspi.local: no such host)
i was able share the service its showing in the server but this error was appearing. Also i could'nt find any method to access this from an mqtt client or do i need to run a zrok instance to acess this in the client app??
I am guessing you have at least two devices:
The mqtt server device running zrok share must be able to look up the DNS name "raspi.local" before it can connect to the zrok controller at raspi.local:18080.
This name "raspi.local" looks like a typical hostname for a RasPi that is only valid on the same device. You need a static IP address for your RasPi device and a global DNS name like "pi.example.com" that the other mqtt device can resolve to find the IP address.
