Adding WSTunnel functionality to the project.

[gturner30]

Summary

Adds optional support for bridging a tunnel's WireGuard traffic over WSTunnel (WebSocket transport), to help users get through networks/firewalls that block or throttle raw WireGuard UDP traffic while still allowing standard HTTPS/WebSocket traffic.

This is opt-in per tunnel and fully backward compatible. Tunnels that don't enable it behave exactly as before.

Motivation

Some networks (corporate firewalls, certain public WiFi, restrictive ISPs/countries) use Deep Packet Inspection to specifically identify and block WireGuard's UDP handshake pattern, even when the destination port is otherwise open. Wrapping the same traffic inside a WebSocket connection (which looks like ordinary HTTPS traffic) is a common, well-established way to route around this without needing a different VPN protocol entirely.

How it works

WireGuard itself is never made aware that WSTunnel is involved. When enabled:

1. A local WSTunnel client subprocess is started, listening on 127.0.0.1:<ephemeral-port>.
2. The tunnel's peer endpoint is rewritten (only in the config handed to wireguard-go) to point at that local port instead of the real server.
3. The WSTunnel client relays UDP datagrams between that local port and the configured WSTunnel server over a WebSocket connection, which the server unwraps back to plain UDP toward the real WireGuard endpoint.
4. The UI and any diagnostics (live tunnel view) always show the real configured server, not the local bridge address.

This keeps the change entirely additive with no modifications to the WireGuard/AmneziaWG userspace (libwg-go) implementation needed.

What's included

• New :wstunnel Gradle module bundling the official prebuilt wstunnel v10.6.1 client binary (BSD-3-Clause), verified against its published checksum.
• Per-tunnel settings screen (enable toggle, server URL, optional HTTP upgrade path prefix, optional TLS SNI override).
• Room migration adding the new tunnel fields, with mapper updates so they persist correctly.
• Engine-level wiring so DDNS/seamless-recovery/IPv6-recovery reconciliation never overwrites the bridged peer's endpoint back to the real server (which would silently bypass the bridge).
• License attribution added to the in-app licenses screen.

Known limitations

• arm64-v8a only. Upstream wstunnel does not currently publish prebuilt Android binaries for armeabi-v7a/x86/x86_64. The feature is hidden/disabled automatically on unsupported ABIs (this covers the large majority of current Android devices).
• If the WSTunnel server itself becomes unreachable mid-session, the bridge subprocess does not currently get proactively restarted by network-change handling.

Testing

• Built and installed a debug APK; confirmed the tunnel connects successfully both with and without WSTunnel enabled.

[zaneschepke]

Hello!

Thanks a lot for this. I really appreciate the effort.

I do want to support things like wstunnel, but I’d rather not bake these protocols directly into WG Tunnel. The goal is to keep the project focused on WireGuard and WireGuard derived protocols (like AmneziaWG).

Instead of supporting other protocols directly, I’m planning to add upstream proxy support. This would let WG Tunnel proxy its WireGuard tunnels through other tools/protocols.

Reasons for going this route:

• Keep WG Tunnel focused and relatively slim
• Give users flexibility to integrate with pretty much any other protocol/tool they need
• Avoid opening the floodgates to requests for supporting a bunch of other protocols directly in the app

Are you open to pivoting in that direction instead? I can add more details here on what this should look like if you’re interested in contributing to it. Otherwise we can close this PR.

Thanks again!

[gturner30]

Hey,
That all makes perfect sense to me, and I'm happy to pivot and help with the upstream proxy implementation.
My original motivation was to avoid DPI, and that can be solved by moving the code I already wrote into a separate WSTunnel app (or by running WSTunnel in something like Termux) and adding that as an upstream proxy.

The only thing I want to flag before starting any development work on upstream proxy support is that given Wireguard is UDP, many upstream proxies won't support it.

Either way, happy for this PR to be closed, and I'll continue to use my fork until I can build a separate app :)