On Mon, Jun 3, 2019 at 3:49 AM Aleksandar Lazic <al-hapr...@none.at> wrote:
> nutinshell have another use case which is a `socks4-redirect`
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498007739

Is there such a specification for `socks4-redirect`?  (I've looked in
the original SOCKS4 specification and didn't find any mention about
it:  https://www.openssh.com/txt/socks4.protocol .)

> I see at least this use cases from this thread.
> * client with explicit SOCKS support -> HAProxy SOCKS frontend -> normal 
> backend
> / servers -- useful for routing only specific domains through HAProxy
> The suggestion here is to handle socks in the same way as proxy protocol. As
> mentioned above I don't think that's that easy as the socks protocol is a
> request response system which proxy protocol isn't.

Based on the SOCKS4 specification, the protocol is "request-reply"
only in the first interaction (one request / one reply), and after
that it goes into tunnel mode:
For a successful request,
the SOCKS server gets ready to relay traffic on both directions. This
enables the client to do I/O on its connection as if it were directly
connected to the application server.

> There are also not only "the" socks protocol as there is socks4,socks4a and
> socks5 with different feature sets and requirements. From what I seen in the
> thread is only socks4 with command **connect** expected. This means that the
> client sends the destination ip and port therefore haproxy does not need to
> resolve the destination.

Yes, that is the way I've proposed it:  SOCKS4 plain-and-simple, IPv4
only, no DNS, no other extensions.  (At least not in the first
iteration, although perhaps IPv6, without DNS resolutions, might also
be useful, as per https://tools.ietf.org/html/rfc3089 )

> From my point of view it is at least a similar option like `accept-proxy`
> required for example `accept-socks(4|4a|5)`
> One of the question which is open is make `accept-proxy` and
> `accept-socks(4|4a|5)` sense?
> @cipriancraciun and others opinions?

I think `accept-socks` would be enough (for the frontend), because
from what I gather the protocol version can be decoded from the actual
headers.  (Perhaps a new sample might be added to determine that SOCKS
is used, and which version, to then force certain versions.)

However, just like in case of `accept-proxy`, on the backend (better
said server) side an `send-socks(4|5)` would be needed to allow the
administrator to choose the downstream protocol.  (SOCKS4a from what I
gather added support for DNS resolution, which we don't actually

> * client (with / without) SOCKS support -> HAProxy frontend -> SOCKS enabled
> server -- useful for traffic filtering, and redirection to a proper SOCKS 
> proxy;
> The reason why the patch from alec isn't enough is that answer
> ~~~~
> From what I read @alec-liu implemented SOCKS4 in the backend only as a way to
> submit requests for to a "fixed" server IP through a "fixed" SOCKS4 proxy 
> server.
> ~~~~

Exactly, I underline once more, that the main difference with the
other proposed patch, is that in my proposal the server IP is the IP
of the SOCKS gateway, and that the sent IP in the SOCKS4 header is the
one in `src`, just as it happens in case of the (HA)PROXY protocol.)

> I think this feature would be nice in HAProxy but I also think it's a huge
> amount of work and increases the complexity to debug any errors.

In case of only supporting SOCKS4 as an alternative to the (HA)PROXY
header, the amount of work should be minimal, except that one also has
to read the initial reply from the SOCKS gateway.

Unfortunately I'm not that acquainted with the HAProxy internals, but
if one could pin-point me where in the "reply" path I should include
the response handling I could take a stab at it if I can find some
time.  Some time ago Willy provided me some pointers, but I bet given
the recent work to support HTTP/2, a lot has changed in the interim.


Reply via email to