Transport Plugins

[luker983]

Problem

One of the major shortfalls of Wiretap is that without third party tools, the top-level transport is always WireGuard/UDP.

A workaround for wrapping the transport in TCP is provided in the Experimental section of the README: https://github.com/sandialabs/wiretap?tab=readme-ov-file#tcp-tunneling, but raises the complexity of deployment quite a bit and involves other binaries.

Proposed Solution

Add the concept of "Transport Plugins" to the Wiretap binary that allows for tunneling WireGuard over other protocols (I'm thinking websockets as the first proof of concept, but could be DNS/ICMP/etc.)

There will be performance issues with these plugins and require an additional listener on the client, so we should be clear about the trade-offs in the docs.

What I think we need for v1 of this feature:

• [ ] Optional transport plugin argument, changing the transport that servers use to communicate back to clients
• [ ] Implementation of at least one transport plugin (e.g., websockets)
• [ ] Client-side listener to unwrap the underlying WG data and forward it to the proper interface

[Aptimex]

Would the current Relay connection be tunneled inside the new transports, or would the selected transport replace the Relay connections? If the latter, would we need to worry about adding another layer of encryption, or just rely on the transport to provide it (possibly losing that layer of encryption if the protocol doesn't natively provide one)?

Can you provide an example of what the commands might look like to setup and use one of the transports? That might help me better visualize how this would work. I'm not sure I see the benefit vs just relying on a tool like Chisel or Ligolo-ng to begin with if you need to use a different protocol.