Add option to map (force) port use on the server for reverse tunnels #274
Conversation
siepkes
changed the title
src/tunnel/server.rs
Outdated
| .iter() | ||
| .find_map(|allow| { | ||
| if let AllowConfig::ReverseTunnel(allow) = allow { | ||
| if remote.protocol.is_reverse_tunnel() { |
There was a problem hiding this comment.
No need of this check, as you already know at this point that a ReverseTcp has been requested.
src/tunnel/server.rs
Outdated
| .find_map(|allow| { | ||
| if let AllowConfig::ReverseTunnel(allow) = allow { | ||
| if remote.protocol.is_reverse_tunnel() { | ||
| return allow.port_mapping.get(&remote.port).cloned(); |
|
Hello, I am not against the idea of it, but it should be supported for all reverse tunnels :) |
This change adds a `port_mapping` option to the `ReverseTunnel` definition in the (YAML) restriction file. It maps ports on the server side from X to Y (X:Y). Where X is the originally requested port by the client and Y is the port which will be used to listen on server-side. For example with `10001:8080` configured and a client which connects using `-R tcp://10001:localhost:80` the server will listen on port 8080 instead of 10001. The originally requested ports (NOT the mapped ports) still needs to be allowed via the `ports` directive. This is for example useful when dealing with lots of clients and you don't want to coordinate port use on all the clients but centrally on the server.
siepkes
force-pushed
the
server-port-mapping
branch
from
b5a7eb7
to
58d2e49
Compare
Yes, definitely! Sorry, should have been clear about that it was merely a first proof on concept to iterate on and to get a feel about how you thought about such a feature. Since your open to it I've also implemented the other ones but I still need to test the thing (so hold yer horses with any merging 😉 )
I'm still new to Rust and I'm struggling a bit with this one. Simply changing to |
|
I did some basic testing ( TCP port with forced mapping, Client which has TCP forced mappings but not for the requested port, etc.) and functionally it all seems to work. |
|
Alright, thank you for the PR ;} For the clone vs cloned, cloned should be only available for iterator. But essentially it does the same thing than clone. |
…#274) This change adds a `port_mapping` option to the `ReverseTunnel` definition in the (YAML) restriction file. It maps ports on the server side from X to Y (X:Y). Where X is the originally requested port by the client and Y is the port which will be used to listen on server-side. For example with `10001:8080` configured and a client which connects using `-R tcp://10001:localhost:80` the server will listen on port 8080 instead of 10001. The originally requested ports (NOT the mapped ports) still needs to be allowed via the `ports` directive. This is for example useful when dealing with lots of clients and you don't want to coordinate port use on all the clients but centrally on the server.
…#274) This change adds a `port_mapping` option to the `ReverseTunnel` definition in the (YAML) restriction file. It maps ports on the server side from X to Y (X:Y). Where X is the originally requested port by the client and Y is the port which will be used to listen on server-side. For example with `10001:8080` configured and a client which connects using `-R tcp://10001:localhost:80` the server will listen on port 8080 instead of 10001. The originally requested ports (NOT the mapped ports) still needs to be allowed via the `ports` directive. This is for example useful when dealing with lots of clients and you don't want to coordinate port use on all the clients but centrally on the server.
This change adds a
port_mappingoption to theReverseTunneldefinition in the (YAML) restriction file.It maps ports on the server side from X to Y (X:Y). Where X is the originally requested port by the client and Y is the port which will be used to listen on server-side.
For example with
10001:8080configured and a client which connects using-R tcp://10001:localhost:80the server will listen on port 8080 instead of 10001. The originally requested ports (NOT the mapped ports) still needs to be allowed via theportsdirective.This is for example useful when dealing with lots of clients and you don't want to coordinate port use on all the clients but centrally on the server.
Let me know if this works for you and the project or if you have (other) ideas on it!