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: ~~~~ https://www.openssh.com/txt/socks4.protocol 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 need.) > * 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. Ciprian.