websockets through Squid

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 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