feat: support HTTP CONNECT proxy connection for built-in MQTT bridge by jarhodes314 · Pull Request #3531 · thin-edge/thin-edge.io

jarhodes314 · 2025-04-03T15:58:34Z

Proposed changes

Attempts to provide a solution to #3228 using HTTP CONNECT.

Adds support for HTTP CONNECT proxying to the Cumulocity bridge config in the built-in bridge as well as support for websocket connections, so we can use standard HTTPS proxying. Initially intended for enabling a customer to test this solves their issue.

MQTT proxying is only supported with the built-in bridge. If proxying is configured with the mosquitto bridge enabled, a warning will be displayed by tedge connect/tedge-mapper, and the direct connection will not use the proxy (since this matches the behaviour of the bridge we are creating in this instance).

I've tested this locally with go-gost and it works as intended both for MQTT and HTTP.

To enable proxy support:

tedge config set proxy.address http://localhost:8080
tedge config set proxy.username user
tedge config set proxy.password pass
tedge config set proxy.no_proxy "google.com"

Still TODO (now all done):

Support tedge connect direct c8y connection
Combine scheme and address fields in tedge config
Make sure tedge config docs don't refer to Cumulocity
Replace unwraps in HTTP proxy configuration with a result-based solution
~~Check the behaviour of HTTP/MQTT proxying with regard to HTTP_PROXY/NO_PROXY environment variables~~
Log proxy settings in the tedge connect output
Add a no_proxy configuration to allow users not

Types of changes

Bugfix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
Documentation Update (if none of the other choices apply)
Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

MQTT connection through proxy #3228

Checklist

I have read the CONTRIBUTING doc
I have signed the CLA (in all commits with git commit -s. You can activate automatic signing by running just prepare-dev once)
I ran just format as mentioned in CODING_GUIDELINES
I used just check as mentioned in CODING_GUIDELINES
I have added tests that prove my fix is effective or that my feature works
I have added necessary documentation (if appropriate)

Further comments

codecov · 2025-04-03T16:12:13Z

Codecov Report

Attention: Patch coverage is 46.44809% with 98 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/core/tedge/src/cli/connect/command.rs	9.67%	28 Missing ⚠️
...common/tedge_config/src/tedge_toml/tedge_config.rs	36.11%	18 Missing and 5 partials ⚠️
crates/core/tedge/src/cli/connect/c8y.rs	0.00%	7 Missing ⚠️
crates/core/tedge/src/cli/log.rs	0.00%	6 Missing ⚠️
crates/core/tedge/src/bridge/config.rs	44.44%	5 Missing ⚠️
...s/common/certificate/src/cloud_root_certificate.rs	76.47%	4 Missing ⚠️
crates/core/plugin_sm/src/plugin.rs	25.00%	3 Missing ⚠️
crates/core/tedge/src/cli/certificate/cli.rs	0.00%	3 Missing ⚠️
crates/core/tedge/src/cli/http/cli.rs	0.00%	3 Missing ⚠️
crates/core/tedge_mapper/src/aws/mapper.rs	0.00%	3 Missing ⚠️
... and 8 more

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

github-actions · 2025-04-24T12:16:09Z

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
626	0	3	626	100	1h50m30.815964s

reubenmiller · 2025-04-24T21:21:54Z

Update There seems to still be some communication that does not go through the proxy. I've pushed a commit (9004271) which adds a system test which also sets iptables rules to block any traffic not coming from the gost proxy (excluding loopback traffic of course).

The problem occurs somewhere within the tedge connect c8y command. If the rules are enabled only after the connection is enabled, then the tedge-mapper-c8y built-in bridge can connect successfully via the proxy.

$ tedge connect c8y
connect to Cumulocity cloud.:
        device id: TST_tweak_piercing_rasp
        cloud profile: <none>
        cloud host: iot.latest.stage.c8y.io:8883
        auth type: Certificate
        certificate file: /etc/tedge/device-certs/tedge-certificate.pem
        cryptoki: false
        bridge: built-in
        service manager: systemd
        mosquitto version: 2.0.11
Creating device in Cumulocity cloud... ✗

I've also been able to partially verify the connection and it seems to be ok though I'm still trying to get a setup which blocks all traffic that does not go through the proxy to confirm all aspects are covered.

Though whilst exploring two things came up:

Add proxy info to the tedge connect c8y output to make it easier to debug
Would it be better to remove the need for proxy.type and just let the user specify the kind of proxy in the proxy.address config?

If it would be supported then it would make it easier to configure as it only needs one setting. Separating the username password is still ok
as it allows users to protect that information if necessary.
```
tedge config set proxy.address https://127.0.0.1:8080

tedge config set proxy.address http://127.0.0.1:8080
```

mappers Signed-off-by: James Rhodes <jarhodes314@gmail.com>