yes i did modify the config.yml
with my ip
The router service must restart after changing the config file. Please let me know if the problem persists afterwards. I will investigate why it was not added to the config when you ran the bootstrap script.
EDIT: found the issues causing the router to have incorrect subject alternative names and sent a pull request to fix
1 Like
while creating pull request which branch should i choose from base branch
The default branch is "main." We decided not to fix the IP SAN issue in that PR because the implementation proved too controversial. Draft PR has that part of the discussion: let linux/docker controller/router address be IPv4/IPv6 by qrkourier · Pull Request #2438 · openziti/ziti · GitHub
These will still work without changing how the router deployment works:
- use DNS instead of an IP for production routers
- provide a config.yml instead of generating one
- edit the router's generated config.yml to add any DNS or IP SANs you wish
i had to poweroff the raspberrypi which is running the server it got the ip address to change and i followed your instruction to change every instance of ip to dns name but it is still retaining that ip and trying to establish a connection to old ip
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/common/metrics/pool_metrics.go:50","func":"github.com/openziti/ziti/router/xgress_edge.(*listener).Listen.Goroutin>
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/router/router.go:544","func":"github.com/openziti/ziti/router.(*Router).startXgressListeners","level":"info","msg">
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/router/router.go:544","func":"github.com/openziti/ziti/router.(*Router).startXgressListeners","level":"info","msg">
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/router/xgress_edge/accept.go:126","func":"github.com/openziti/ziti/router/xgress_edge.(*Acceptor).Run","level":"in>
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/router/router.go:722","func":"github.com/openziti/ziti/router.(*Router).getInitialCtrlEndpoints","level":"info","m>
Sep 27 16:28:04 raspberrypi ziti[6879]: {"file":"github.com/openziti/ziti/router/router.go:555","func":"github.com/openziti/ziti/router.(*Router).startControlPlane","level":"info","msg":"r>
Sep 27 16:28:04 raspberrypi ziti[6879]: {"endpoint":{"tls:raspi.local:1280":{}},"file":"github.com/openziti/ziti/router/env/ctrls.go:95","func":"github.com/openziti/ziti/router/env.(*netwo>
Sep 27 16:28:04 raspberrypi ziti[6879]: {"endpoint":"tls:raspi.local:1280","file":"github.com/openziti/ziti/router/env/ctrls.go:134","func":"github.com/openziti/ziti/router/env.(*networkCo>
Sep 27 16:28:07 raspberrypi ziti[6879]: {"endpoint":"tls:raspi.local:1280","error":"error connecting ctrl (dial tcp 192.168.1.11:1280: connect: no route to host)","file":"github.com/openzi>
Sep 27 16:28:10 raspberrypi ziti[6879]: {"endpoint":"tls:raspi.local:1280","error":"error connecting ctrl (dial tcp 192.168.1.11:1280: connect: no route to host)","file":"github.com/openzi>
~
I think you changed the IP SAN to a DNS SAN in the router config and the router is still trying to connect to the controller on 192.168.1.11:1280.
I assume you have this config:
ctrl:
endpoint: tls:192.168.1.11:1280
You may change the value of endpoint to the controller's correct address, but changing the controller's address is intricate and may require re-enrolling identities and routers if you encounter certificate verification errors. At a minimum, you must set a DNS SAN in the controller config matching the endpoint address used by routers.
from: Router Configuration Reference | OpenZiti
You may change routers' addresses at will, but ensure the new address is shown as the value of advertise, e.g.,
listeners:
- binding: edge
address: tls:0.0.0.0:3022
options:
advertise: 127.0.0.1:3022
this is the config file entry
listeners:
# bindings of edge and tunnel requires an "edge" section below
- binding: edge
address: tls:0.0.0.0:3022
options:
advertise: raspi.local:3022
do i need to enroll the router again??
No, the router will begin advertising the new address when you restart it to load the new configuration.
The controller's address was always "raspi.local:1280" or it was changed to "192.168.1.11:1280"?
If you need to change a standalone controller's address, ensure you have a DNS or IP SAN in the controller's server certificates matching the new address. In case you are using the Linux, Docker, or K8S (prod) deployments with an auto-generated configuration, then you must use a DNS name, not an IP address, and it is only necessary to update the input value for the address to the new DNS name and restart the controller. Finally, you must change each router and identity's configuration to use the new address or re-enroll.
@Anzal-calixto thank you for clarifying in the private channel that you are not looking for a solution like the "personalized frontend" (public access to a TCP proxy). Instead, you are looking for private access from mobile app to MQTT topic.
There is no mobile SDK for zrok (Node.js, Python, Go). I will guide you toward the OpenZiti mobile SDKs (Kotlin, Swift).
Do you plan to begin with iOS or Android?
Well currently the app is being developed for Android . And what changes I need to make in the gateway side??
I need to confirm with the app development team regarding which language they are working on
I believe you clarified earlier that a gateway is a device or node providing the MQTT topic the mobile apps will consume, correct?
You will need an OpenZiti tunneler running on each gateway. The best tunneler pick will depend on how the MQTT server is accessed. Is it running as a Linux service, Docker container, or Kubernetes pod?
Yes
The mosquito mqtt broker inside the gateway is running as a linux service
Great. I have two deployment alternatives for you:
- install the ziti-edge-tunnel.service on each gateway - this provides a tunneler service that allows each gateway to become a ziti service provider or consumer (server or client or both)
- install the ziti-router.service on each gateway - in addition to the capabilities of the tunneler service, the router provides a more robust, multi-link connection to the ziti fabric
These are both good options. The first is a little simpler because there's no need to configure the service. It's a one-time install and enroll operation, and then it's on autopilot.
The second option may be better in the long run for a more resilient Ziti network, and it requires a bit more configuration.
1 Like
understood how will the SDK aka Client will access the tunnel? what do we need to do in the server side?
On each gateway you'll have two things running: the MQTT server and a Ziti tunneler. In the Ziti controller, you'll configure a Ziti service like "mqtt-service" with a target like "127.0.0.1:8883," or wherever the MQTT server is listening. The tunneler will begin hosting "mqtt-service" when it is granted bind permission in a Ziti service policy.
The mobile app will import the Kotlin SDK. Each mobile app install will enroll with a token (JWT) from the Ziti controller so it can save an identity/context in app storage that includes a private key and certificate. The mobile app must be configured for the "mqtt-service" with the Ziti SDK. The identity that was enrolled by the app must be granted permission to dial that Ziti service with a Ziti service policy.
i am assuming you are referring to server?
how this will behave in a multiple gateway environment?
one more thing Ken it doesnt really matter if its a private/public access all that matters is app should be able to connect to the endpoint as if its a normal mqtt broker with or without SDK.
You can design your system so that many gateways share a Ziti service equally, or each gateway is uniquely addressable.
To dive deeper, I'd need a clearer picture of the stack. It will help if we define terms and draw a simple diagram. Let's define the relationships between them like one-to-many vs. many-to-many, and whatever you think is necessary or helpful. You have these components, right?
- many edge devices publishing IoT data to many gateways
- many gateways aggregating and translating IoT data to one MQTT broker
- many Android apps viewing state provided by one MQTT broker
sorry for the late response. I have two or more devices to test this setup and i will draw a diagram for your understanding and i will share it to you