[squid-users] debug a failure connection

[Amos Jeffries]

On 13/03/20 12:15 am, Vieri wrote:
> Hi,
> 
> I'm trying to understand what could cause Squid not to connect to the following site:
> 
> 2020/03/12 11:48:24.115 kid1| 17,4| AsyncCallQueue.cc(55) fireNext: entering FwdState::ConnectedToPeer(0x561b8b5c7918, local=10.215.144.48:51303 remote=1.2.3.4:443 FD 784 flags=25, 0x561b8a7ee5b8/0x561b8a7ee5b8)
> 2020/03/12 11:48:24.115 kid1| 17,4| AsyncCall.cc(37) make: make call FwdState::ConnectedToPeer [call219229]
> 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8b5c7918
> 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8b5c7918
> 2020/03/12 11:48:24.115 kid1| 45,9| cbdata.cc(419) cbdataReferenceValid: 0x561b8a7ee5b8
> 2020/03/12 11:48:24.115 kid1| 17,3| FwdState.cc(447) fail: ERR_SECURE_CONNECT_FAIL "Service Unavailable"
>         1.2.3.4:443
> 
> 
> A direct connection by-passing Squid shows that the https site opens fine but with a 3DES cipher. In my Squid 4 test I set this temp values just in case:
> tls_outgoing_options 


> flags=DONT_VERIFY_PEER

Prevents TLS security being checks. Any problems will be hidden from the
proxy admin and logs.

They still break TLS. You just wont be told what happened. This is
pretty much the opposite of what you want to be doing.

> cipher=ALL

Enables OpenSSL ciphers that client or server may may detect as
forbidden and trigger termination. eg ROT13 and NUL encryption.

If you leave this unset instead, Squid's library will use the machines
default ciphers. You need to see what those are to know which ciphers to
add or remove to fix any problem with the set.


>  options=ALL

Enables lots of OpenSSL features which are a) experimental - breaking
TLS, or b) highly dangerous - breaking TLS, or c) forbidden by an
endpoint - terminating TLS.

Also the opposite of what you want. Leave unset to see what the library
is preferring. Then identify the problem. Then set any specific option
you might need for the problem you find.



There may be multiple problems leading to the same error message,
affecting different transaction(s). So troubleshooting has to be careful
here. Find a repeatable request, debug that for one fix. Then see if the
error still shows up for other traffic and repeat to find the second
problem, etc.


> 
> I don't know how to interpret the messages previous to the ERR_SECURE_CONNECT_FAIL line. Do I need to send them all? Which debug options would be more useful?
> 

The [call219229] is the ID of a Call informing FwdState of the problem.
Find where it was a) created, and b) scheduled to 'dial'. That will tell
you what operation was happening that hit the problem. It may be the
source, or may have received info from somewhere else - trace backwards
until you find the start of the error handlers.

NP: debug info in the TLS logic is a bit absent so you may find it more
useful or faster to get a packet dump and inspect with with Wireshark.


If you do not know what a message means and unsure it can be helpful to
include just in case. All messages from *one* transaction should be
sufficient to see the problem with that transaction.

Note though this list has a 100KB limit on total mail size to avoid hugs
log posts being posted to everyone.


Amos