MySqlConnector к серверу MySQL на той же системе видит попытку подключения с IP-адреса вместо локального хоста.

Я столкнулся с проблемой, которую, несмотря на некоторые исследования и различные попытки устранения неполадок, не смог решить или действительно понять. Я подозреваю, что проблема связана с поведением MySqlConnector.

Мы запускаем приложение на dotnet в системе Linux и хотим подключиться к базе данных MySQL на той же системе. Пользователь, которого мы используем, может подключаться только с localhost.

Вот вывод:

2025-01-06 13:41:36.819 +01:00 [INF] OpenConnection => 

Host=localhost;Username=myuser;Password='mypass';Database=; Connection Timeout=360;Allow User Variables=True
2025-01-06 13:41:37.460 +01:00 [ERR] Error connecting to mysql server AccessDenied
MySqlConnector.MySqlException (0x80004005): Access denied for user 'myuser'@'10.15.15.142' (using password: YES)
   at MySqlConnector.Core.ServerSession.ReceiveReplyAsync(IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnector/Core/ServerSession.cs:line 885

IP-адрес, который виден (10.15.15.142), это IP-адрес LAN, назначенный первому интерфейсу системы. Здесь я теряюсь, мы указываем подключение к localhost, но MySQL видит подключение как идущее с этого IP-адреса. Почему?

Открытие оболочки и введение “mysql -u myuser -p” позволит подключиться без проблем.

Исследование предположило принудительное использование Unix-сокета для подключения, указывая “Protocol=unix”, но это не привело к улучшению:

2025-01-06 14:05:53.176 +01:00 [INF] OpenConnection => 
Host=localhost;Username=myuser;Password='mypass';Database=; Connection Timeout=360;Allow User Variables=True;Protocol=unix
2025-01-06 14:05:53.263 +01:00 [ERR] Error connecting to mysql server Failed
MySqlConnector.MySqlException (0x80004005): Cannot find Unix Socket at localhost

Мы также пробовали использовать 127.0.0.1 вместо localhost для строки подключения, но результат тот же. Также проверили, что файл hosts в системе настроен правильно. Мы также подтвердили, что смена пользователя на myuser@% работает как положено, но как только она изменяется на myuser@localhost, проблема возвращается.

Версии:

Microsoft.AspNetCore.App 7.0.20 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
mysql  Ver 8.0.35 for Linux on x86_64 (MySQL Community Server - GPL)

Когда пакеты поступают из одного источника, их сопровождающие пытаются сделать так, чтобы все работало без проблем. Но похоже, что .NET клиентская библиотека, вероятно, поступает не из того же источника, что и MySQL серверный пакет. У каждого пакета есть некоторые настройки по умолчанию — пути и так далее, и в данном случае некоторые из этих настроек не совпадают.

Одной из таких настроек, которую мы обнаружили, является путь к Unix-сокету по умолчанию. Должен быть способ его указать, так что в общем случае, когда говорится, что сокет не найден, но другая программа (консольный клиент mysql) может его найти, вы можете просто указать путь, и это должно сработать.

Еще одно различие заключается в том, что “стандартный” libmysqlclient автоматически переключается на Unix-сокеты, когда он видит localhost, но ваша клиентская библиотека этого не делает, поэтому ей нужно указать использовать Unix-сокеты.

Наконец, обратите внимание на нетривиальное поведение предоставления доступа в отношении имен хостов. Ваши таблицы предоставления MySQL, вероятно, содержат предоставления для username@localhost, а не для username@whatever или подстановки username@%. Такие предоставления для localhost определенно работают, когда вы подключаетесь через Unix-сокет. Они также должны работать для TCP от localhost к localhost, но это зависит от разрешения имен, и необычные настройки разрешения имен могут делать его похожим на что-то другое, даже когда вы, кажется, используете адреса localhost. Например, ваше соединение может исходить от 127.0.1.1, который может быть связан с каким-то альтернативным именем в файле hosts, так что когда происходит обратное разрешение на сервере, происходит вывод этого альтернативного имени вместо localhost, и сервер не распознает соединение как исходящее от localhost и не применяет доступы для localhost.