Вопрос или проблема

Ошибка рукопожатия шифровального набора TLS 1.2 при подключении к SQL Server с помощью sqlcmd

        sqlcmd \
        --server "$UTT_SQLDB_SERVERNAME" \
        --database-name "$UTT_SQLDB_DATABASE" \
        --user-name "$UTT_SQLDB_USERNAME" \
        --password "$UTT_SQLDB_PASSWORD"

sqlcmd \
    -S "$UTT_SQLDB_SERVERNAME" \
    -U "$UTT_SQLDB_USERNAME" \
    -P "$UTT_SQLDB_PASSWORD" \
    -d "$UTT_SQLDB_DATABASE"

root@50f7a7519b2b:/var/www/html# sqlcmd -S $UTT_SQLDB_SERVERNAME -U $UTT_SQLDB_USERNAME -P $UTT_SQLDB_PASSWORD -d $UTT_SQLDB_DATABASE
Sqlcmd: Ошибка: Microsoft ODBC Driver 17 для SQL Server : TCP Provider: код ошибки 0x2746.
Sqlcmd: Ошибка: Microsoft ODBC Driver 17 для SQL Server : клиент не может установить соединение.

Код ошибки TLS 40: Это указывает на сбой при установлении соединения во время обмена TLS. Это происходит, когда клиент и сервер не могут согласовать протоколы шифрования или шифры.

Ошибка SChannel 1205: Это ошибка Windows, связанная с SChannel (Безопасный канал), который является компонентом, ответственным за обработку шифрования SSL/TLS. Ошибка 1205, как правило, означает, что имел место несоответствие в конфигурации TLS между клиентом и сервером.

root@50f7a7519b2b:/var/www/html# openssl s_client -connect $UTT_SQLDB_SERVERNAME:1433 -tls1_2
CONNECTED(00000003)
root@50f7a7519b2b:/var/www/html# openssl s_client -connect $UTT_SQLDB_SERVERNAME:1433 -tls1_1
CONNECTED(00000003)
root@50f7a7519b2b:/var/www/html# openssl s_client -connect $UTT_SQLDB_SERVERNAME:1433 -tls1  
CONNECTED(00000003)

Ответ или решение

Проблема, с которой вы столкнулись, связана с ошибкой рукопожатия TLS при попытке подключения к SQL Server из Docker-контейнера. Хотя вы можете успешно подключиться к серверу из хостовой системы, но не можете сделать это из контейнера — это довольно распространенная проблема, учитывая, что в окружениях Docker могут быть разные конфигурации.

Анализ проблемы

1. Сертификаты и протоколы: Хотя вы можете установить соединение с SQL Server с помощью OpenSSL, это не обязательно означает, что ваш клиент sqlcmd может использовать те же шифры, что и OpenSSL. Версия ODBC драйвера и его совместимость с TLS могут вызывать проблемы с шифрованием.

2. Разные версии библиотек: На хост-системе используется openssl 3.0.2, в то время как в контейнере openssl 3.0.14. Версии библиотек могут иметь разные настройки по умолчанию, что может влиять на совместимость шифров.

3. Конфигурация Docker: Контейнер может иметь разные сетевые настройки и зависимости от конфигурации Docker. Возможно, что в контейнере что-то мешает правильному использованию ODBC драйвера.

Рекомендации по решению проблемы

1. Проверка шифров: Убедитесь, что ODBC драйвер, используемый в контейнере, поддерживает те же шифры, что и сервер. Вы можете выполнить команду для отображения доступных шифров:

   openssl ciphers -v

   Убедитесь, что необходимые для работы шифры и протоколы включены.

2. Обновление ODBC драйвера: Убедитесь, что вы используете последнюю версию ODBC драйвера 17 для SQL Server. Иногда обновления могут содержать исправления, которые улучшают совместимость.

3. Проверка настроек TLS на сервере: Убедитесь, что сервер SQL настроен для поддержки необходимых протоколов и шифров. Возможно, потребуется изменить настройки на стороне сервера.

4. Запуск контейнера с использованием --network host: Если вы еще не попробовали это, попробуйте запустить контейнер с флагом --network host. Это обеспечит использование сетевых настроек вашего хоста и может помочь с проблемами совместимости.

   docker run --network host your-docker-image

5. Анализ логов SQL Server: Обратите внимание на дополнительные ошибки в журналах SQL Server. Они могут дать дополнительную информацию о причинах при отказе в подключении.

6. Протестируйте на другой версии контейнера: Возможно, у вас изменится поведение при использовании другого базового образа Docker. Попробуйте начать с базового образа, отличного от Debian 12, например, с Ubuntu.

Пример команды для тестирования

Попробуйте следующее, чтобы увидеть, может ли sqlcmd подключиться:

sqlcmd -S "$UTT_SQLDB_SERVERNAME" -U "$UTT_SQLDB_USERNAME" -P "$UTT_SQLDB_PASSWORD" -d "$UTT_SQLDB_DATABASE" -N

Флаг -N требует, чтобы соединение было защищенным.

Заключение

Если ни одно из решений не поможет, возможно, стоит рассмотреть возможность использования другого клиента, например, sql-cli или другого инструмента, который может использовать другие механизмы подключения. Кроме того, не забудьте проверить справочную документацию Microsoft и Bugzilla для известного поведения, связанного с их ODBC драйверами и соответствующими библиотеками.