Closed afontenot closed 1 year ago
Hey! Thanks for the suggestion. This sounds the same as #6.
The first use-case I had for onetun
was for an unprivileged client. Having an unprivileged server that listens for TCP handshakes from the tunnel is possible, just not implemented.
Thanks for the response! I think this is close enough to the same issue that maybe it would have the same solution. I'm okay with closing this if that turns out to be the case.
I think the end goal is a little different though. Usually the goal of a reverse mode has to do with firewalls. E.g. there are ssh servers are both ends, A wants to open a shell on B, but B is behind a firewall that doesn't allow incoming connections. Solution: B connects to A in reverse mode.
I don't care about this feature at all. What I'm after is something that can act like a boring, vanilla Wireguard server on the remote end, just without root. I think onetun
could do this without having to implement a control protocol to activate reverse tunneling.
Having an unprivileged server that listens for TCP handshakes from the tunnel is possible
If I understand correctly, this wouldn't involve TCP, it would just be UDP as before. This would not involve any changes to the Wireguard protocol. As I imagine it working, onetun
would have two new CLI flags:
--listen 192.168.4.1:51820
--peer BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB:192.168.4.3/32
Or maybe just a --listen-conf
if parsing the Wireguard config files is not too hard.
What I meant is that onetun would behave like a regular WireGuard peer over UDP, just that instead of initiating TCP/UDP connections through the tunnel, it would be receiving TCP/IP handshakes (processed by smoltcp)
In other words, onetun has to create virtual server sockets instead of clients in this mode.
Okay, I'll close this. Thanks for responding!
From the documentation:
Maybe the documentation just leaves this out, but it's not obvious to me why onetun itself can't function as the remote WG endpoint. Couldn't it just listen on an unprivileged port and forward packets as requested to a destination port?
This might not be a common use case, but it seems like it might be nice to use onetun in cases where neither end of the connection has root.