`all proxy server down` when using `trojan` as socks backend

[ryanerwin]

When I try to run curl on with moproxy setup with a single trojan socks5 backend, I'm getting:

 ❯❯❯ curl -i -4 -vvv www.duckduckgo.com
*   Trying 176.34.155.23:80...
* TCP_NODELAY set
* Connected to www.duckduckgo.com (176.34.155.23) port 80 (#0)
> GET / HTTP/1.1
> Host: www.duckduckgo.com
> User-Agent: curl/7.65.1
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

When I check the moproxy log, I see this as the curl is executed:

[DEBUG] incoming 192.168.1.100:54986
[DEBUG] dest V4(176.34.155.23:80)
[TRACE] registering with poller
[DEBUG] connected with Ok(V4(127.0.0.1:2001))
[INFO] connect proxy error: early eof
[TRACE] deregistering handle with poller
[WARN] all proxy server down

When I check the trojan socks5 proxy log, I see:

Jul 06 22:35:11 ryxps trojan[7641]: [2019-07-06 22:35:11] [ALL] 127.0.0.1:56210 incoming connection
Jul 06 22:35:11 ryxps trojan[7641]: [2019-07-06 22:35:11] [ERROR] 127.0.0.1:56210 unknown protocol
Jul 06 22:35:11 ryxps trojan[7641]: [2019-07-06 22:35:11] [INFO] 127.0.0.1:56210 disconnected, 0 bytes received, 0 bytes sent, lasted for 0 seconds

Due to the timing of these in the logs, it seems definitive that iptables is forwarding my connection request to moproxy and through to my backend socks proxy, but the formatting of the request when moproxy provides it doesn't seem to be working for my socks proxy.

I followed the redsocks method for creating the iptables rule, but also an exception so that anything running as uid = proxy would not get redirected to moproxy.

my iptables rules

``` ❯❯❯ iptables -t nat -A MOPROXY -d 0.0.0.0/8 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 10.0.0.0/8 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 100.64.0.0/10 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 127.0.0.0/8 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 127.0.0.0/8 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 169.254.0.0/16 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 172.16.0.0/12 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 192.168.0.0/16 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 198.18.0.0/15 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 224.0.0.0/4 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -d 240.0.0.0/4 -j RETURN ❯❯❯ iptables -t nat -A MOPROXY -p tcp -m owner ! --uid-owner proxy -j REDIRECT --to-ports 2080 ❯❯❯ iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner proxy -j MOPROXY ```

Any tips on how to further debug this?

Note, running on Arch Linux (rolling release) with a stock kernel and all packages updated to current.

[sorz]

It may caused by the (in-)compatibility of SOCKSv5 implementation. I saw this issue on another backend, but not yet to check whether your situation is the same case, although the behaviors are similar.

The SOCKSv5 client implemented on moproxy is actually not in compliance with the RFC 1928. It bypasses parts of SOCKS handshaking (version checking, auth method negotiation, etc.) by sending all the bytes the server would expect in once, directly, w/o waiting for server's ask.

This is simpler to implement and save several RTTs delay for each connection, but was found not be such friendly to some SOCKS servers.

I will try to improve this when I got time.

[sorz]

Just confirmed, trojan don't allow we do SOCKS in this way.

https://github.com/trojan-gfw/trojan/blob/9caf35153fe151ccb642c43d250c03d08c014d57/src/clientsession.cpp#L138-L139

[ryanerwin]

Thanks for checking into it @sorz In the mean time I setup redsocks combined with an iptables based roundrobbin, but definitely would be far better to use moproxy to distribute the load!

I will try to improve this when I got time.

Cool!

[sorz]

Hi, can you try out the latest code on master? Thanks.

[ryanerwin]

Awesome! Tried it and it works great now!