[GH-ISSUE #117] Support SOCKS for accessing exposed TCP ports #67

New issue

Open

opened 2026-05-05 10:59:37 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 10:59:37 -06:00

Owner

Originally created by @RoganDawes on GitHub (May 26, 2020).
Original GitHub issue: https://github.com/mmatczuk/go-http-tunnel/issues/117

When exposing TCP ports from a go-http-tunnel client via the server, currently we are required to choose a port on the server to map that port to. e.g server:2222 maps to client:22. However, this does not work well when you have multiple clients all wanting to expose the same client port on the same server port.
The SOCKS protocol allows the client to inform the proxy of the hostname and port that the client wishes to connect to, simply by exposing a single TCP port. Using SOCKS4a or SOCKS5, it is possible to pass the actual hostname to the proxy, rather than allowing the caller to resolve the name to an IP address. In this way, go-http-tunnel can be informed of the hostname and port that the client is attempting to connect to, and can look up the connected client names and ports in the registry to satisfy the request.
This is actually very similar to the existing SNI protocol sniffer method for determining the name that is being requested, but also allows the port to be specified.
For security purposes, the SOCKS protocol also allows for credentials to be passed to authenticate the connection attempt, which could be a valuable additional feature, allowing the go-http-tunnel client to control whether an incoming connection should be permitted or not, which is otherwise not currently possible.
Sample client configuration file might look like:

    server_addr: SERVER_IP:5223
    tunnels:
      webui:
        proto: http
        addr: localhost:8080
        auth: user:password
        host: webui.my-tunnel-host.com
      ssh:
        proto: socks
        addr: 192.168.0.5:22
        remote_addr: ssh.my-tunnel-host:22
        auth: user:password
      tls:
  	proto: sni
  	addr: localhost:443
  	host: tls.my-tunnel-host.com

On the server side, there could be a "-socksAddr" option that specifies the SOCKS port to listen to, disabled by default.

Edited to change the proto: tcp to proto: socks to indicate that the remote_addr should not necessarily be opened as a listening port on the server immediately on client connection, but rather that the socks client should request a connection to that port. Otherwise there is a bit of ambiguity there, especially if the hostname provided actually resolves to an IP address on the tunneld host.

Originally created by @RoganDawes on GitHub (May 26, 2020). Original GitHub issue: https://github.com/mmatczuk/go-http-tunnel/issues/117 When exposing TCP ports from a go-http-tunnel client via the server, currently we are required to choose a port on the server to map that port to. e.g server:2222 maps to client:22. However, this does not work well when you have multiple clients all wanting to expose the same client port on the same server port. The SOCKS protocol allows the client to inform the proxy of the hostname and port that the client wishes to connect to, simply by exposing a single TCP port. Using SOCKS4a or SOCKS5, it is possible to pass the actual hostname to the proxy, rather than allowing the caller to resolve the name to an IP address. In this way, go-http-tunnel can be informed of the hostname and port that the client is attempting to connect to, and can look up the connected client names and ports in the registry to satisfy the request. This is actually very similar to the existing SNI protocol sniffer method for determining the name that is being requested, but also allows the port to be specified. For security purposes, the SOCKS protocol also allows for credentials to be passed to authenticate the connection attempt, which could be a valuable additional feature, allowing the go-http-tunnel client to control whether an incoming connection should be permitted or not, which is otherwise not currently possible. Sample client configuration file might look like: ``` server_addr: SERVER_IP:5223 tunnels: webui: proto: http addr: localhost:8080 auth: user:password host: webui.my-tunnel-host.com ssh: proto: socks addr: 192.168.0.5:22 remote_addr: ssh.my-tunnel-host:22 auth: user:password tls: proto: sni addr: localhost:443 host: tls.my-tunnel-host.com ``` On the server side, there could be a "-socksAddr" option that specifies the SOCKS port to listen to, disabled by default. Edited to change the `proto: tcp` to `proto: socks` to indicate that the `remote_addr` should not necessarily be opened as a listening port on the server immediately on client connection, but rather that the socks client should request a connection to that port. Otherwise there is a bit of ambiguity there, especially if the hostname provided actually resolves to an IP address on the `tunneld` host.

gitea-mirror commented

2026-05-05 10:59:39 -06:00

Author

Owner

@RoganDawes commented on GitHub (May 26, 2020):

Here is a possible starting point: https://github.com/armon/go-socks5

@RoganDawes commented on GitHub (May 26, 2020): Here is a possible starting point: https://github.com/armon/go-socks5

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/go-http-tunnel#67

No description provided.

Rows
Columns