Устранение распространенных проблем подключения к RDS из экземпляров EC2

Когда приложение на EC2 не может подключиться к RDS, сначала определите тип ошибки. Тайм-аут обычно означает, что трафик где-то блокируется на пути. Быстрый отказ в соединении (connection refused) означает, что хост был достигнут, но порт не принял соединение. Ошибка аутентификации означает, что сетевой путь, вероятно, работает, и проблема перешла на уровень пользователей базы данных, паролей, SSL, аутентификации IAM или прав доступа.

Это различие экономит время. Не сбрасывайте пароли при сетевом тайм-ауте и не открывайте группы безопасности при неправильном пароле. Работайте от экземпляра EC2 наружу: DNS, доступность порта, группы безопасности, маршрутизация подсетей, NACL, статус RDS, затем аутентификация базы данных.

Предварительные условия для успешного подключения

Прежде чем приступить к устранению неполадок, убедитесь, что следующие основные элементы настроены правильно:

1. Согласованность VPC: Для простейшей конфигурации оба экземпляра EC2 и RDS должны находиться в одной VPC, хотя возможно подключение между разными VPC через пиринг VPC.
2. Зоны доступности (AZ): Убедитесь, что инфраструктура вашего приложения (EC2) может достичь инфраструктуры базы данных (RDS) через разные AZ, если это необходимо, хотя маршрутизация обычно обрабатывает это внутри VPC.
3. Сетевая доступность: Подтвердите, что экземпляр EC2 работает и имеет активное сетевое подключение (например, он может выходить в интернет или к другим внутренним сервисам).

Шаг 1: Проверка конфигураций групп безопасности (самая частая причина)

Группы безопасности действуют как виртуальные брандмауэры как для вашего экземпляра EC2, так и для экземпляра RDS. Неправильная конфигурация здесь является источником подавляющего большинства ошибок подключения.

A. Проверка группы безопасности EC2

Ваш экземпляр EC2 должен иметь исходящие правила, разрешающие трафик на порт базы данных. По умолчанию большинство групп безопасности разрешают весь исходящий трафик (0.0.0.0/0 по всем протоколам/портам), но это стоит проверить.

B. Проверка входящих правил группы безопасности RDS

Это критически важный шаг. Группа безопасности RDS должна явно разрешать входящий трафик от экземпляра EC2.

Действие для проверки:

1. Перейдите в консоль RDS и выберите свой экземпляр базы данных.
2. Перейдите на вкладку Connectivity & security и найдите связанные группы безопасности.
3. Отредактируйте входящие правила.
4. Убедитесь, что существует правило, разрешающее трафик на конкретный порт базы данных (например, 3306 для MySQL, 5432 для PostgreSQL).
5. Источником для этого правила должен быть идентификатор группы безопасности вашего экземпляра EC2 или конкретный диапазон частных IP-адресов экземпляра EC2, если вы не используете ссылки на группы безопасности.

Лучшая практика: Всегда ссылайтесь на идентификатор группы безопасности исходного ресурса (EC2), а не используйте конкретные IP-адреса в поле источника. Это позволяет соединению сохраняться, даже если частный IP-адрес экземпляра EC2 изменится (например, при масштабировании или перезагрузке).

Пример входящего правила (PostgreSQL):

Тип	Протокол	Диапазон портов	Источник
PostgreSQL	TCP	5432	sg-012345abcdef67890 (ID группы безопасности вашего EC2)

Шаг 2: Подтверждение публичной доступности и конечной точки RDS

Если ваш экземпляр EC2 не находится в частной подсети или требует подключения через публичный интернет (обычно не рекомендуется для продакшена), вы должны проверить публичную доступность RDS.

A. Настройка публичной доступности

1. В консоли RDS проверьте вкладку Connectivity & security для экземпляра RDS.
2. Если Publicly accessible установлено в No, база данных доступна только через частные сетевые пути, такие как ресурсы в той же VPC или подключенные сети через пиринг, Transit Gateway, VPN или Direct Connect, если это разрешено правилами маршрутизации и безопасности.
3. Если Publicly accessible установлено в Yes, не рассматривайте это как упрощение для продакшен-доступа. Подтвердите, что у клиента есть действительный публичный маршрут, и ограничьте группу безопасности RDS минимально возможным диапазоном источника. Экземпляр EC2 в той же VPC обычно должен использовать частный путь.

B. Проверка конечной точки

Убедитесь, что приложение на экземпляре EC2 использует правильную конечную точку RDS (DNS-имя) и правильный порт. Несоответствия здесь приводят к тайм-аутам или отказам в соединении.

Используйте утилиту telnet или nc (netcat) с вашего экземпляра EC2 для проверки базовой TCP-доступности к конечной точке и порту RDS:

# Для MySQL на порту 3306
telnet your-rds-endpoint.rds.amazonaws.com 3306

# Для PostgreSQL на порту 5432
nc -zv your-rds-endpoint.rds.amazonaws.com 5432

Успешное подключение приводит к пустому экрану или немедленному сообщению о соединении. Ошибка (тайм-аут или отказ) указывает на сетевую блокировку, обычно группы безопасности или маршрутизацию подсетей.

Шаг 3: Анализ конфигурации подсетей и маршрутизации

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

A. Сетевые ACL (NACL)

Сетевые ACL — это брандмауэры без сохранения состояния, работающие на уровне подсети. Если вы реализовали пользовательские NACL, они могут блокировать обратный трафик, необходимый для завершения соединения.

• Проверьте NACL как для подсети EC2, так и для подсети RDS.
• Убедитесь, что как входящие, так и исходящие правила разрешают трафик на порт базы данных и диапазон эфемерных портов (1024-65535) для обратного трафика.

B. Маршрутизация между VPC или гибридная маршрутизация

Подключения к базам данных RDS обычно используют обычную маршрутизацию VPC, а не шлюзовую конечную точку типа S3. Если EC2 и RDS находятся в разных VPC или подключены из локальных сетей, проверьте полный частный маршрут в обоих направлениях. Пиринг VPC, Transit Gateway, VPN и Direct Connect требуют записей в таблицах маршрутизации, а также совместимых правил групп безопасности и NACL.

Шаг 4: Проверка конфигурации экземпляра базы данных

Если сетевое подключение подтверждено (Шаг 2 успешен), проблема находится внутри самого движка базы данных.

A. Учетные данные и авторизация базы данных

Проверьте имя пользователя, пароль и имя базы данных, используемые приложением, подключающимся с экземпляра EC2. Сервисы RDS, такие как MySQL и PostgreSQL, применяют строгую аутентификацию пользователей.

B. Группы параметров и статус базы данных

1. Статус базы данных: Убедитесь, что статус экземпляра RDS — Available. Если он изменяется, создает резервную копию или перезагружается, подключения будут неудачными.
2. Группы параметров: Проверьте любые пользовательские группы параметров, примененные к экземпляру RDS. Некоторые настройки (например, skip-networking в некоторых конфигурациях MySQL, хотя это менее распространено в управляемом RDS) могут препятствовать подключениям.

C. Аутентификация базы данных IAM (если используется)

Если вы используете IAM для аутентификации базы данных вместо паролей, убедитесь, что роль IAM, прикрепленная к экземпляру EC2 (или профиль пользователя, запускающего приложение), имеет правильные разрешения (rds-db:connect) и что строка подключения правильно включает необходимые токены аутентификации.

Порядок устранения неполадок

Используйте этот приоритетный контрольный список для быстрого решения проблем:

1. Проверка порта: Может ли EC2 достичь порта RDS с помощью telnet или nc? Не полагайтесь на ICMP ping; RDS — это не обычный сервер, который можно так диагностировать.
2. Группа безопасности RDS: Разрешает ли входящее правило трафик от группы безопасности EC2 к порту RDS?
3. NACL: Открыты ли как входящие, так и исходящие правила для необходимых портов (порт базы данных + эфемерные порты)?
4. Конечная точка/Учетные данные: Правильна ли строка подключения и действительны ли учетные данные?
5. Статус БД: Находится ли экземпляр RDS в статусе Available?

Если проверка порта не удалась, оставайтесь на сетевом уровне, пока она не пройдет успешно. Если проверка порта прошла успешно, но клиент базы данных не работает, прекратите изменять правила VPC и внимательно прочитайте ошибку базы данных. Большинство инцидентов EC2-to-RDS становятся намного проще, если рассматривать сетевую доступность и аутентификацию базы данных как отдельные вопросы.