Dear Toradex Community,
Because our edge devices (based on Torizon OS, with Colibri/Verdin) are often used within a dedicated network at a customers site,
Internet endpoints needed from the edge device have to be known in advance (and usually also registered somewhere in a firewall rule), like Docker registry, AWS IoT or Torizon Platform OTA endpoints.
In that regard we would like to have some kind of a proxy under our control for all these things to get a “single” endpoint (at least per protocol), but I couldn’t find any possibility to configure aktualizr in that regard.
Maybe I’m also looking into a wrong direction and you have better ideas.
Looking forward for input and inspiration.
I’m curious to learn more about the proxy you intend to setup. Aktualizr doesn’t have support for configuring an explicit forward proxy, but it’s something we might consider supporting. This issue of devices behind firewalls is on our radar!
Additionally the Remote Access Service uses ssh, and currently no way to configure a proxy.
Some consideration for your use-case was done during the design of the Remote Access Service (RAS) as described from this snippet (from internal architecture docs)
For the first implementation of this feature [Remote Access], tunneling is not supported. The device connects directly to RAS using SSH. However, we expect that in the future some devices will be deployed to networks where TCP traffic on non standard ports is not allowed. Therefore, we want to prepare our architecture so we can feasibly accommodate changes that allow devices in these networks to be accessed remotely.
For example, if the device is deployed to a network where only TCP traffic on port 443 is allowed, we could setup a WebSocket tunnel between the device and RAS. The device could then connect to RAS using SSH tunneled through WebSockets.
All this is to say, let us know what you were thinking with the proxy! This is a recurring problem for us as well.
I see two ways of solving this challenge on our side. Either by using a generic proxy (e.g. SOCKS5) for any kind of traffic and with the help of e.g. socksify on the client side or by using application specific proxies, like HTTP proxy.
We don’t use the Remote Access feature from Torizon, so I can’t speak for the SSH case (but these things are covered I guess, as you mentioned e.g. by tunnelling through websocket).
Some thoughts from my side regarding generic vs specific proxy:
When using a generic proxy solution, a working configuration needs to be found per application. By “working” I mean tackling application and system constraints/configuration on the edge device,
like firewall, application (endpoint awareness, client side loadbalancing, socks wrapping, fork/exec handling, …) and sometimes also other issues like lookups (e.g. DNS).
One could also use VPN with one specific endpoint, but that’s a different story and not just a “proxy” case imo (however still on the table an additional option tbh).
A specific proxy (application level), does it per application (or protocol / API) obviously. In case of HTTP, just set http_proxy and it works out of the box (ignoring camel case and no_proxy issues for now).
Looking at our endpoints a device needs to reach:
private/public docker registry: works with docker engine HTTP proxy configuration
AWS IoT (HTTPS, MQTT over Websocket): works with HTTP proxy configuration or even having custom endpoints (although not yet sure about the data tunneling; might be inspiring for Toradex btw)
Torizon Cloud: tbh, no idea which client application is doing what and how many endpoints are needed for having a working Torizon OTA. I hope that aktualizr is the only thing needed. So aktualizr could be wrapped with socksify on the client side and having a SOCKS proxy on our end redirecting all traffic to Torizon Cloud. Or even better, proxy support out of the box (but not sure which protocols are in use and how it works internally)…
Do you have a list of client side applications (Torizon OS), endpoints and protocols relevant for a working Torizon Cloud service (from a device point of view)? That would be great as a starter.
FYI: We’re currently in ideation mode for this “proxy” challenge and it’s not a blocker right now. But I expect that we will work on a solution in 3-6 weeks and therefore trying to gather as much information as we can beforehand.
BR,
Lukas
P.S. Sorry for the long post, got into rubber duck talk somehow
Wrapping things in SOCKS should work, i personally find myself wondering if setting up a tunnel interface to your separate hosted service might be simpler/cleaner instead of worrying about each application… but then you gotta manage the routes and the keys so as always… you gotta weigh the options.
Anyways, you asked about network endpoints that Torizon OS uses. I need to get this into a docs page soon… this is mostly off the top of my head, so it could be slightly wrong but I will check and verify.
so as always… you gotta weigh the options.