@kotelok

БАЗОВЫЙ ВОПРОС
При каких сценариях вызов 'SqlConnection.Open' может навсегда забирать управление и не возвращать никаких ошибок?


ПОДРОБНОСТИ
Дано:
1. Сервис на net-core-3.1, запущенный на локальной машине в докер-контейнере.
2. SQLServer 2014-й на другой машине в локальной сети.
3. Внутри сервиса есть подключение к SQLServer и через EF, и, для теста, напрямую через 'SqlConnection'.

Далее такое вот странное поведение. Подключение во всех случаях идёт на один тот же SQLServer с полностью идентичными данными (аутентификация по логину/паролю):
1. Запуск сервиса напрямую на хост-машине, SqlConnection.Open: ОК.
2. Телнет и sqlcmd с хост-машины: ОК.
3. Телнет и sqlcmd изнутри докер-контейнера: ОК (т.е. маршрут есть, порт доступен, сервер соединение принимает и позволяет выполнять sql-запросы).
4. SqlConnection.Open изнутри докер-контейнера: НИЧЕГО.

Т.е. в 4-м случае вызов просто блокирует поток и более никогда ничего не делает (на всякий случай час подождал). Он не выдаёт таймаут, не выдаёт никаких исключений, не говорит про ошибку аутентификации или шифрования, он просто бесконечно выполняется и не возвращает управление.

Если вместо внешнего SQLServer (при прочих идентичных параметрах окружения/сборки) используется SQLServer в соседнем докер-образе, то в 4-м тесте всё ок, и подключение, и запросы. Точно так же всё ок, при попытке подключения на похожий 2014-й SQLServer, запущенный на локальной хост-машине.

Добавлено через 6 минут
Нюансы:
1. Подключение по IP+порт, т.е. DNS не задействован.
2. Это первое и единственное подключение в рамках запущенного сервиса, т.е. истощение пула подключений вряд ли возможно (да и там, насколько я помню, тоже какое-то исключение должно быть).

Добавлено через 2 часа 46 минут
Вопрос закрыт. Проблема в багованном докер-образе:
1. В том, что сделан на базе Debian-10 (3.1.6-buster-slim) баг стабильно повторяется.
2. Если взять за основу какой-нибудь другой линукс-дистрибутив, например Ubuntu-18 (3.1.6-bionic), то поключение к базе проходит корректно.

Добавлено через 56 минут
Ещё уточнение: похоже, проблема всё же в реализации 'Microsoft.Data.SqlClient'. Если используется тот дефолтный (версии 1.0.19269.1), что идёт в составе core-3.1, то баг повторяется. Если же явно через nuget добавить сборку версии 2.0, то на том же проблемном сценарии появляется вполне нормальная ошибка настройки шифрованного канала:
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)

Вероятно, в debian-образе по умолчанию просто немного иначе настроено ssl/tls (возможно, нужно что-то в конфиги прописать или какие-то библиотеки доустановить), а дефолтный 'SqlClient' не умеет правильно обрабатывать и выдавать соответствующую ошибку.

4