SSH tunnel problems in Linux

[altbert]

I'm failing to create a load balanced connection using ssh tunnels in Linux

OS: Arch linux and Ubuntu Linux

ssh tunnel command:

ssh -D 127.0.0.1:6555 {remote_user}@{remote_ip} -N

go-dispatch-proxy command: sudo ./go-dispatch-proxy -lport 6556 -tunnel 127.0.0.1:6555

[FATAL] IP address not associated with an interface 127.0.0.1

go-dispatch-proxy list command: ./go-dispatch-proxy -list

--- Listing the available addresses for dispatching [+] enp5s0, IPv4:192.168.0.101

When trying the proxy with the IP of the iface i don't get the error, but i do get a connection refused

sudo ./go-dispatch-proxy -lport 6556 -tunnel 192.168.0.101:6555

[INFO] Load balancer 1: 192.168.0.101, contention ratio: 1 [INFO] Local server started on 127.0.0.1:6556 [WARN] 192.168.0.101:6555 {dial tcp4 192.168.0.101:6555: connect: connection refused}

[extremecoders-re]

The commands look fine to me. Does the SOCKS proxy on 127.0.0.1:6555 work normally with other applications?

[altbert]

Yes the SSH tunnel works fine standalone, i tried it with Firefox and ProxyChains.

[altbert]

Load balancing through the listed interfaces works fine.

sudo ./go-dispatch-proxy -lport 6556 192.168.0.101

[INFO] Load balancer 1: 192.168.0.101, contention ratio: 1 [INFO] Local server started on 127.0.0.1:6556 [DEBUG] cdimage.debian.org:443 -> 192.168.0.101:0 [DEBUG] gemmei.ftp.acc.umu.se:443 -> 192.168.0.101:0

Test command: proxychains wget 'https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.9.0-amd64-netinst.iso'

By the looks of it, maybe the problem remains in the verification done when selecting if the load balancing is done through tunnel or interface?.

[altbert]

When commenting the following in the main.go source file (function parse_load_balancers()): 197: //if iface == "" { 198: // log.Fatal("[FATAL] IP address not associated with an interface ", lb_ip) 199: //}

The load balancing of the ssh tunnel works fine.

[SirSAC]

Hello, this issue is caused because the SSH servers not have an interface name, thanks to posting this issue for making me to search a solution.

[altbert]

You're welcome. Thanks for the rapid response and solution.

[extremecoders-re]

@SirSAC Thanks for investigating into the issue. It was because of trying to obtain the interface name in tunnel model which doesn't make sense.

@joaquinaltamirano I have made the fixes. Please check if the binaries here work for you and I'll create a new release. https://ci.appveyor.com/project/extremecoders-re/go-dispatch-proxy/build/artifacts

[altbert]

Tested. Now it works. Thanks