-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS Handshake failures with Go 1.23 #2296
Comments
Hi @dan-lind thanks for raising an issue on the Cloud SQL Proxy! The Cloud SQL Proxy forwards local traffic to port From our docs:
Let me know as this is a common cause for the issue you are seeing 😄 |
Am I reading your config correctly that you're connecting to 34 instances? |
Hi! Like I wrote in "Additional details", connecting using the MySQL CloudSQL proxy in Datagrip works without any issues. Another tcpdump on that traffic shows that this connection also happens on 3307.
|
This config has 34 entries, yes. However I've tried reducing it down to a single entry as well, it doesn't change anything. |
That's very interesting, because the built-in driver (which uses the Java Connector) does effectively exactly the same thing. Have you tried connecting through the Proxy using a CLI tool, or something other than Datagrip to determine if Datagrip is involved? |
Yes I have. I've tried "dumbing things down" as much as possible, for example to rule out any issues with the unix sockets.
then using the mysql client (v8.4)
yields the same result
tcpdump looks similar
|
Thanks for the report. In that case I think we need to look into this -- that's wholly unexpected and something we definitely don't see in our automated testing. Out of curiosity do you see the same behavior across instances? |
Yes, same across instances
tors 12 sep. 2024 kl. 21:49 skrev Eno Compton ***@***.***>:
… Thanks for the report. In that case I think we need to look into this --
that's wholly unexpected and something we definitely don't see in our
automated testing.
Out of curiosity do you see the same behavior across instances?
—
Reply to this email directly, view it on GitHub
<#2296 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADJ2OD2XA5EVYLJ5AGVT6DZWHV5NAVCNFSM6AAAAABODAKRY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBXGEYTGNZTGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Hi @dan-lind this looks like an issue on the server side. Do you happen to have a support contract with Google? If so you could open a case and they will have access to check your server logs. Let me know, otherwise I can try and figure out a way to take a look deeper for you. |
We do yes, I've reached out to them referring to this issue. |
Perfect, that is great to hear. |
I'm experiencing the same issue when trying to connect through the proxy. I receive a "connection reset by peer" error during the handshake process. Here’s a snippet from my logs:
This issue occurs consistently (direct access & via python's connectors), I have tried reinitializing from my main device & my alt but nothing seems to work. Other users (on same project, with the same permissions) are not facing this issue even though they are following the same connection procedure & running the same OS with the latest updates. UPDATE: Downgrading to v2.11.3 seems to have solved the issue for now as a work around, will try to identify the version where the issue started UPDATE 2: After some git bisecting the commit that started the issue was |
@TokieSan Thanks for the detailed analysis and extra data points! I would recommend pinning to an older version for now, in the meantime I will investigate this further to see if there is maybe something on the server side that is causing issues with the latest Go 1.23 TLS changes. |
Confirming that downgrading to v2.11.3 solve the issue for me as well! |
Thanks for confirming @dan-lind , appreciate it. I am just curious if you were able to successfully open up a support case for this issue? If so I can escalate it to get folks to look at the server side and see if we can pinpoint the issue. |
Yes, I have a support case open! EDIT: @jackwotherspoon I don't know how this usually works, but I've asked in my support case for them to reach out to you. |
That is perfect, thanks |
@dan-lind @TokieSan I am taking a look at the server side to see if there are any issues with the use of Go 1.23 In the meantime, I wanted to point out #2294 which was also an issue for 2.13.0 when connecting to a Private IP Cloud SQL instance via a VPN...
I wonder if one of you could try starting the v2.13.0 Proxy with |
Yes! |
@dan-lind Great to hear it! I am going to look at open Go issue's and see if I need to create one as it seems like the new default preferences implemented in golang/go#67061 are not playing nicely with VPNs |
I think we have a similar problem with SOCKS proxies too. GoogleCloudPlatform/alloydb-auth-proxy#714 |
FYI GoogleCloudPlatform/alloydb-auth-proxy#714 (comment) We should probably make this a feature request, since the root cause of these TLS handshake failures are buggy TLS servers. |
Bug Description
When attempting to connect through the proxy, I'm getting connection reset by peer
Starting the proxy is fine
but when I attempt to make the actual connection, I get
In the client (Datagrip 2024.2.1) I see the error
Socket is not connected.
On the CloudSQL side, I can also see a warning log in Logs explorer like
1893634 [Warning] [MY-000000] [Server] Failed to connect to mysql: 1893634. Server-side error number: 1159
Stacktrace
Steps to reproduce?
This happens every time I try connecting though the terminal
Environment
cloud-sql-proxy --config-file ~/cloudsql/cloudsql-config.toml
Content of
cloudsql-config.toml
Additional Details
This happens only when I setup the proxy using the terminal. If I use Intellij/Datagrip, and use the built in MySQL CloudSql proxy driver, I can connect without issues.
The text was updated successfully, but these errors were encountered: