So I've worked with this a bit more and I've got it to the point that its reaching out to the socks server and making a request. The two issues I see now is that 1) any failure (server not up, server denies request, etc) results in a segv and 2) its requesting the wrong address from the server (it looks like ATS is requesting the IP/Port of its side of the connection to the socks server - which is how I know ATS will segv if the server denies the request)
On Sat, May 2, 2015 at 8:15 PM, CJ Ess <[email protected]> wrote: > I've spent some time looking into the SOCKs support in ATS (or maybe > former SOCKS support is more accurate) > > SOCKS support is present in every ATS. The define that enables it is Here > <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/I_Socks.h#L31>, > There > isn't an option to switch it on or off in configure. > > Its not documented in recent ATS versions but you can piece together > information from Here > <http://mail-archives.apache.org/mod_mbox/trafficserver-users/201411.mbox/%3CCAE2_gsVvj=UJqEPYfEDxpUg_cp+dhs2_9oEeNmVNOeH6YFL=f...@mail.gmail.com%3E> > , Here > <https://www.websense.com/content/support/library/web/v76/wcg_help/sokpvars.aspx> > , and Here <https://gist.github.com/piotrbulinski/9396189>. And there is > an open Jira to update the documentation Here > <https://issues.apache.org/jira/browse/TS-2513> > > Once you get past that its really tough to trigger the code - I added > these entries to records.config: > CONFIG proxy.config.socks.socks_needed=1 > CONFIG proxy.config.socks.default_servers=<socks_server_ip>:<socks_port> > And for added measure I added this line to socks.config: > dest_ip=0.0.0.0-255.255.255.255 parent="<socks_server_ip>:<socks_port>" > > However, none of those items seemed to have any effect - all the outgoing > traffic from ATS still went direct, there were no connections to the socks > server. Eventually I resorted to forcing ATS to select the socks path Here > <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/UnixNetProcessor.cc#L202> > . > > It turns out that the socks code has issues with IPV6, and even if your > not using IPV6 but are on a host with IPV6 capability you fail an assert > Here > <https://github.com/apache/trafficserver/blob/bc6acc0b84a8c53d2022298dfa9d3dc6541e4b83/iocore/net/Socks.cc#L65>. > And I'm not the first one to find that, see Here > <https://issues.apache.org/jira/browse/TS-2482> > > And if you work around that then you eventually segfault (not sure where > in the code): > traffic_server: Segmentation fault (Address not mapped to object > [0x24])traffic_server - STACK TRACE: > > /home/me/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac079] > /lib64/libpthread.so.0[0x38e340f710] > > /home/me/ats/bin/traffic_server(_ZN18ParentConfigParams10findParentEP15HttpRequestDataP12ParentResult+0x28)[0x4e0f38] > > /home/me/ats/bin/traffic_server(_ZN10SocksEntry10findServerEv+0x15a)[0x74118a] > > /home/me/ats/bin/traffic_server(_ZN10SocksEntry4initEP10ProxyMutexP18UnixNetVConnectionhh+0x855)[0x742605] > > It looks like the core issue is with how ATS selects the outgoing address > of Socks connections. Socks5 technically supports IPV6, but socks4/4a does > not, so when resolving names for Socks only IPv4 addresses should be > considered. However, most socks servers are capable of doing their own name > resolution and TOR (probably the most popular thing using socks right now) > would prefer to do its own name resolution, so the best solution might be > to pass through FQDNs which is supported by socks 4a and 5. Beyond that the > address we are connecting to is the address of the socks server and I don't > think that is being resolved for some reason. > > BTW, the current SOCKS support hard codes the authorization parameters of > the socks server and thats probably sufficient for one person behind a > proxy, However, for more then one person behind a -caching- proxy that > probably not sufficient, if the server needs authorization we should > probably pass through the username:password from the Proxy-Authorization > details or return the client a 407 if not present/declined. > > It looks like the closest anyone has come to fixing socks in recent times > was Here <https://issues.apache.org/jira/browse/TS-803>, I'm not sure how > his fix worked or if its still appropriate for the current ATS. > > I'm hoping that there is enough here that someone more seasoned would be > inspired to look into it. I'll continue to look at it but I'm not familiar > with the code base so it could be a while before I can contribute much more > then analysis. > > > >
