После перехода на dotnet core 2.2 в Linux подключение к нашей базе данных SQL Azure часто приводит к ошибке подтверждения связи перед входом в систему.

Question

На прошлой неделе мы перенесли нашу производственную среду с .NET Framework 4.6.2 на .NET Core 2.2. Все работает как положено, за исключением того, что теперь мы часто получаем следующую ошибку при подключении к базе данных:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)
   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling)
   at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at System.Data.SqlClient.SqlConnection.Open()

Наша производственная среда использовалась в плане службы приложений Windows 32 bit в Azure. В этой среде у нас почти никогда не было проблем с рукопожатиями перед входом в систему.

Теперь, внезапно после того, как мы перешли на 64-битные контейнеры Linux, эти ошибки начинают появляться несколько раз в день.

Я искал в Интернете решение, но не могу его найти. Кто-нибудь имеет представление о том, что мы должны делать?

Это наша строка подключения:

Server=tcp:{server_url},1433;Data Source={server_url};Initial Catalog={database};Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Max Pool Size=500;

РЕДАКТИРОВАТЬ: Просто чтобы быть ясно: большинство подключений к базе данных SQL успешно. У нас много пользователей на нашем сервере. Однако количество неудачных подключений значительно увеличилось.

Answer 1

Наконец я узнал, что происходит. Мы пропускали соединения в другой части кода (и к другому серверу). Ответы были размещены неправильно. Поскольку разрешенное количество открытых соединений в Linux было меньше, мы столкнулись с этой проблемой быстрее.

Жаль, что сообщение об исключении настолько неоднозначно, но я могу понять, что трудно создать менее неоднозначное исключение.

В любом случае, для людей, которые ищут ответ на ту же проблему: выполните netstat -an на своем сервере, когда столкнетесь с этой проблемой, и проверьте, не ищите ли вы соединения.