I enjoy WireGuard and it's tooling but in this case TLS seems like the better, battle tested option without any significant downsides if all you are doing is HTTP anyways...
I enjoy WireGuard and it's tooling but in this case TLS seems like the better, battle tested option without any significant downsides if all you are doing is HTTP anyways...
Certification also works differently: TLS (and OpenVPN) rely on Certificate Authorities while WireGuard relies directly on the public key of hosts. This has implications in how trust is managed in the network.
MQTT over TLS is pretty standard, and supported out of the box by virtually all clients/brokers. I suspect the same is true for AMQP.
Some time ago I did a set of benchmarks of MQTT+TLS vs MQTT+WireGuard. Although I was rooting for WireGuard to blow TLS out of the water, the overall bandwidth requirements are quite similar. Under normal conditions WireGuard overhead is a bit higher than TLS, though various network pathologies can swing things the other way. The main one being roaming: if the client frequently switches networks, WG tends to handle this far more gracefully than TLS (not surprising given the underlying design and protocols).
In short, TLS can actually be made to work really well in a context like this - I jotted some notes on an optimal setup here: https://medium.com/p/b880285da526
Beyond this, there are some really interesting efforts to unify MQTT and QUIC - from an architectural perspective I feel like that’s the future for IoT comms. (https://www.emqx.com/en/blog/getting-started-with-mqtt-over-...)
Once connected - use it to tunnel traffic back to network.
Anything else would work though (telegram/cloudflare tunnels/...), It's just what I would use.