websockets through Squid

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

websockets through Squid

Vieri
BTW how does Squid decide which IP address to use for "local" here below?

sendRequest: HTTP Server conn* local=<SQUID_PICKS_ONE>

I tried specifying a bind address in http_port and https_port as well as routing traffic from that address out through just one ppp interface, but that doesn't seem to change the way "local" is assigned an address.

Is there a way to keep "local" always the same?

Vieri
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Alex Rousskov
On 10/16/20 10:41 AM, Vieri wrote:
> BTW how does Squid decide which IP address to use for "local" here below?
>
> sendRequest: HTTP Server conn* local=<SQUID_PICKS_ONE>

By default, Squid does not make that decision. The OS does it for Squid.
You can try to force Squid to bind to a specific source address for
outgoing TCP connections using tcp_outgoing_address.


> I tried specifying a bind address in http_port and https_port as well as routing traffic from that address out through just one ppp interface, but that doesn't seem to change the way "local" is assigned an address.

By default, there is no direct relationship between Squid listening port
address and the source address of outgoing TCP connections.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Vieri

On Friday, October 16, 2020, 4:48:55 PM GMT+2, Alex Rousskov <[hidden email]> wrote:

> tcp_outgoing_address.


OK, I fixed the "local" address issue, but I'm still seeing the same behavior.

I pinpointed one particular request that's failing:

2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745) clientAccessCheckDone: The request GET https://ed1lncb62601.webex.com/direct?type=websocket&dtype=binary&rand=1602860196950&uuidtag=G7609603-81A2-4B8D-A1C0-C379CC9B12G9&gatewayip=PUB_IPv4_ADDR_2 is ALLOWED; last ACL checked: all

It is in this log:

https://drive.google.com/file/d/1OrB42Cvom2PNmV-dnfLVrnMY5IhJkcpS/view?usp=sharing

I see a lot of '101 Switching Protocols' and references to upgrade to websockets, but I'm not sure where it is actually failing.

I don't know how to narrow this down further, but if someone could give it another peak I'd be most grateful.

Vieri

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Alex Rousskov
On 10/16/20 11:58 AM, Vieri wrote:

> I pinpointed one particular request that's failing:
>
> 2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745) clientAccessCheckDone: The request GET https://ed1lncb62601.webex.com/direct?type=websocket&dtype=binary&rand=1602860196950&uuidtag=G7609603-81A2-4B8D-A1C0-C379CC9B12G9&gatewayip=PUB_IPv4_ADDR_2 is ALLOWED; last ACL checked: all
>
> It is in this log:
>
> https://drive.google.com/file/d/1OrB42Cvom2PNmV-dnfLVrnMY5IhJkcpS/view?usp=sharing

Thank you, that helped a lot!

I see that Squid decides that the client has closed the connection.
Squid propagates that connection closure to the server. Due to a Squid
bug (or my misunderstanding), cache.log does not contain enough details
to tell whether the client actually closed the connection in this case
and, if it did, whether it did so nicely or due to some TLS error.

I filed bug #5084 in hope to improve handling of this case. At the very
least, the log should categorize the closure, but it is also possible
that the client did not actually close the connection, and Squid is
completely mishandling the situation (in addition to being silent about
it). See https://bugs.squid-cache.org/show_bug.cgi?id=5084 for details.

I cannot volunteer to work on this further right now, but I hope this
triage will help another volunteer (or a paid contractor) to make
further progress.

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Vieri

On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov <[hidden email]> wrote:

> or due to some TLS error.
> I filed bug #5084

 Hi again,

Thanks for opening a bug report.

I don't want to add anything there myself because I wouldn't want to confuse whoever might take this issue into account, but I'd like to comment on this list that I've captured the traffic between Squid and the destination server.
It's here:

https://drive.google.com/file/d/1WS7Y62Fng5ggXryzKGW1JOsJ16cyR0mg/view?usp=sharing

I can see a client hello, Server Hello Done, Cipher Spec, etc, but then it starts over and over again.
So, could it be a TLS issue as you hinted?

I also captured the client console regarding the wss messages (Firefox).
It won't reveal much, but here it is anyway:

https://drive.google.com/file/d/1u4uXW0TCTwClE2kt2nbJSGt5VLdKC03t/view?usp=sharing
NB: the destination server is not the same one as in the packet trace, but that's what the client gets each time (it keeps showing '101 Switching Protocols' over and over).

Please let me know if I should add something to the bug report, or if you see anything of interest in the data I've sent.

Thanks,

Vieri

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Amos Jeffries
Administrator
On 19/10/20 11:07 am, Vieri wrote:

>
> On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov wrote:
>
>> or due to some TLS error.
>> I filed bug #5084
>
>  Hi again,
>
> Thanks for opening a bug report.
>
> I don't want to add anything there myself because I wouldn't want to confuse whoever might take this issue into account, but I'd like to comment on this list that I've captured the traffic between Squid and the destination server.
> It's here:
>
> https://drive.google.com/file/d/1WS7Y62Fng5ggXryzKGW1JOsJ16cyR0mg/view?usp=sharing
>
> I can see a client hello, Server Hello Done, Cipher Spec, etc, but then it starts over and over again.
> So, could it be a TLS issue as you hinted?
>

I'm not seeing anything particularly unusual in there.

The many handshakes are all on different TCP connections, each is
successful, and followed by at least several "application data"
encrypted packets and a TLS connection closure alert before TCP FIN.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Christos Tsantilas
In reply to this post by Alex Rousskov
Hi Vieri,

I attached a patch to bug5084 which may help us to debug the issue:
    https://bugs.squid-cache.org/attachment.cgi?id=3772

The patch is for squid-v5 and produces debug messages at debug level 1.

Regards,
    Christos




On 17/10/20 11:36 μ.μ., Alex Rousskov wrote:

> On 10/16/20 11:58 AM, Vieri wrote:
>
>> I pinpointed one particular request that's failing:
>>
>> 2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745) clientAccessCheckDone: The request GET https://ed1lncb62601.webex.com/direct?type=websocket&dtype=binary&rand=1602860196950&uuidtag=G7609603-81A2-4B8D-A1C0-C379CC9B12G9&gatewayip=PUB_IPv4_ADDR_2 is ALLOWED; last ACL checked: all
>>
>> It is in this log:
>>
>> https://drive.google.com/file/d/1OrB42Cvom2PNmV-dnfLVrnMY5IhJkcpS/view?usp=sharing
>
> Thank you, that helped a lot!
>
> I see that Squid decides that the client has closed the connection.
> Squid propagates that connection closure to the server. Due to a Squid
> bug (or my misunderstanding), cache.log does not contain enough details
> to tell whether the client actually closed the connection in this case
> and, if it did, whether it did so nicely or due to some TLS error.
>
> I filed bug #5084 in hope to improve handling of this case. At the very
> least, the log should categorize the closure, but it is also possible
> that the client did not actually close the connection, and Squid is
> completely mishandling the situation (in addition to being silent about
> it). See https://bugs.squid-cache.org/show_bug.cgi?id=5084 for details.
>
> I cannot volunteer to work on this further right now, but I hope this
> triage will help another volunteer (or a paid contractor) to make
> further progress.
>
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F
>
> Alex.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Alex Rousskov
In reply to this post by Vieri
On 10/18/20 6:07 PM, Vieri wrote:
> Please let me know if I should add something to the bug report

If you can retest with the triage patch attached to the bug report,
please do so an post new error messages produced by the patch (if any).
You can post them to the bug report (preferred) or here.

    https://bugs.squid-cache.org/show_bug.cgi?id=5084

FWIW, Christos has tested the site mentioned in Comment #5 of the bug
report and the triage patch did not show any obvious problems (just
connection closures but it is not clear to me whether those closures
were normal/expected). If your tests, with your problematic site, will
not show anything noteworthy while still failing, then we can rule out
bug 5084 as the suspect (the bug is real, but it may not affect your
specific use case).


Thank you,

Alex.


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: websockets through Squid

Vieri

On Wednesday, November 4, 2020, 3:27:25 AM GMT+1, Alex Rousskov <[hidden email]> wrote:
>   https://bugs.squid-cache.org/show_bug.cgi?id=5084

Hi,

I added a comment to that bug report.
I cannot reproduce the problem anymore, at least not with the latest version of Squid 5.

Thanks,

Vieri
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users