Re: Discussion about "Upstream socks proxy support #82"
On Mon, Jun 3, 2019 at 3:49 AM Aleksandar Lazic 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.
RE: Discussion about "Upstream socks proxy support #82"
Redirect to socks server would be very good for us, we use haproxy to
load balance internal user traffic, happy to use one single rock
stable haproxy solution.
On Mon, Jun 3, 2019 at 8:47 AM Aleksandar Lazic wrote:
>
> Hi.
>
> cipriancraciun, nutinshell and I discussed in the issue above some Socks use
> cases.
>
> Let me summarize the thread here.
>
> cipriancraciun suggest to handle socks similar to proxy protocol.
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498004333
>
> I don't think that socks could be handled in such simple way
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498023780
>
> nutinshell have another use case which is a `socks4-redirect`
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498007739
>
> I thought that a new action for tcp-request content could be a solution.
> https://github.com/haproxy/haproxy/issues/82#issuecomment-498051143
>
>
> 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.
> 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.
>
> 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?
>
> * 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.
> ```
>
> * socks4-redirect "here we want tcp go directly to socks."
>
> I though it could be handled with a new action in `tcp-request content ..` but
> I'm not sure.
>
> ``` for example
> tcp-request content redirect %[src,map(src2dest.txt)] [{if | unless}
> ]
> ```
>
> It would be nice to see how the redsocks2 server handle this redirect as what
> I
> have seen from the code are some firewall tools used for the solution. I had
> never such a requirement.
>
> Src: https://github.com/semigodking/redsocks/blob/master/base.c#L306-L318
>
> @nutinshell It would be very helpful to understand what this `socks4-redirect`
> do on tcp/socks level.
>
> 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.
>
> Please feel free to correct me if I'm wrong at any statement.
>
> Opinions, suggestions, patches?
>
> Best regards
> Aleks
>
Discussion about "Upstream socks proxy support #82"
Hi.
cipriancraciun, nutinshell and I discussed in the issue above some Socks use
cases.
Let me summarize the thread here.
cipriancraciun suggest to handle socks similar to proxy protocol.
https://github.com/haproxy/haproxy/issues/82#issuecomment-498004333
I don't think that socks could be handled in such simple way
https://github.com/haproxy/haproxy/issues/82#issuecomment-498023780
nutinshell have another use case which is a `socks4-redirect`
https://github.com/haproxy/haproxy/issues/82#issuecomment-498007739
I thought that a new action for tcp-request content could be a solution.
https://github.com/haproxy/haproxy/issues/82#issuecomment-498051143
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.
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.
>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?
* 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.
```
* socks4-redirect "here we want tcp go directly to socks."
I though it could be handled with a new action in `tcp-request content ..` but
I'm not sure.
``` for example
tcp-request content redirect %[src,map(src2dest.txt)] [{if | unless}
]
```
It would be nice to see how the redsocks2 server handle this redirect as what I
have seen from the code are some firewall tools used for the solution. I had
never such a requirement.
Src: https://github.com/semigodking/redsocks/blob/master/base.c#L306-L318
@nutinshell It would be very helpful to understand what this `socks4-redirect`
do on tcp/socks level.
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.
Please feel free to correct me if I'm wrong at any statement.
Opinions, suggestions, patches?
Best regards
Aleks
