On 10/15/20 10:08 AM, Vieri wrote: > On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov wrote: >> You should probably follow up with Gentoo folks responsible for this Squid customization. > Squid 5 now builds and installs perfectly on Gentoo Linux with a few > custom changes to the distro's package installation script. I hope > the devs will include these changes so Squid 5 can be readily > available to everyone. Thank you for reporting your fixes to Gentoo. > I added this to Squid 5: > http_upgrade_request_protocols OTHER allow all > Am I right if I state that this should allow any protocol not just WebSockets? Yes. > In other words, I do not need to be specific with > 'http_upgrade_request_protocols WebSocket allow all' unless I want > to, right? Just in case somebody else starts copy-pasting the above rule into their configurations: The standard (RFC 6455) WebSocket protocol name in HTTP Upgrade requests is "websocket". Squid uses case-sensitive comparison for those names so you should use "websocket" in squid.conf. Other than that correction, you are right -- a bare OTHER rule is more risky in general but is sufficient for allowing WebSocket upgrades. > Unfortunately, after reloading Squid 5 the client browser still states the same: > > The connection to wss://ed1lncb65702.webex.com/direct?type=websocket&dtype=binary&rand=1602769907574&uuidtag=9E73C14G-1580-43B4-B8D4-91453FCF1939&gatewayip=MY_IP_ADDR was interrupted while the page was loading. > > And in access.log I can see this: > > [Thu Oct 15 15:52:27 2020].411 29846 10.215.144.48 TCP_TUNNEL/101 0 GET https://ed1lncb65702.webex.com/direct? - ORIGINAL_DST/62.109.225.174 - > [Thu Oct 15 15:52:27 2020].831 125 10.215.144.48 NONE_NONE/000 0 CONNECT 62.109.225.174:443 - ORIGINAL_DST/62.109.225.174 - > [Thu Oct 15 15:52:28 2020].786 11 10.215.111.210 NONE_NONE_ABORTED/000 0 CONNECT 44.233.111.149:443 - HIER_NONE/- - > [Thu Oct 15 15:52:37 2020].414 29870 10.215.144.48 TCP_TUNNEL/101 0 GET https://ed1lncb65702.webex.com/direct? - ORIGINAL_DST/62.109.225.174 - > [Thu Oct 15 15:52:37 2020].919 107 10.215.144.48 NONE_NONE/000 0 CONNECT 62.109.225.174:443 - ORIGINAL_DST/62.109.225.174 - > What does NONE_NONE/000 mean? It is a (relatively minor) bug in Squid. Squid probably forgot to set the exact outcome of the transaction at transaction logging time and probably logged absent status code as 000. We already have a project that should fix the status code handling in such cases. The important part here is the existence of those extra transactions. They may be related to SslBump if you are bumbing this traffic, but then I would expect a slightly different access.log composition. > Where can I go from here? > What can I try to debug this further? The log shows successful tunnel negotiation (two TCP_TUNNEL/101 entries) and potentially problematic transactions. It is not clear (to me) whether they all correspond to the same client interaction. It is possible that the client successfully tunneled some websocket transactions but failed to tunnel others. It is also possible, although less likely, that the client has detected a proxy presence and refused to tunnel despite receiving a successful 101 response from Squid. IMO, further triage requires analyzing debugging cache.log. In my experience, such analysis usually requires developer expertise. You can try posting a link to compressed cache.log containing just the corresponding transactions/interactions with debug_options set to "ALL,9" (this may log passwords, keys, and such so be careful). Somebody here may volunteer to analyze your log for you. https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
