Невозможно подключиться к экземпляру RDS из экземпляра EC2

Ответ 1

Похоже, что когда-то между последней публикацией и этой публикацией, Amazon исправила проблему маршрутизации DNS, потому что теперь все работает отлично для нескольких AZ-адресов...

Ответ 2

У меня была аналогичная проблема, когда я закрутил новый экземпляр EC2, но не изменил параметр в группе безопасности RDS входящего IP-адреса, разрешенного для подключения к порту 3306 моего экземпляра RDS.

Запутанный бит был опцией в панели управления RDS, называемой группами безопасности. Вам не нужно это, чтобы решить проблему.

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

Это должно открыть новую вкладку браузера или окно с информацией о группе безопасности. Найдите несколько вкладок в нижней части, выберите вкладку Входящие и нажмите кнопку Изменить.

Измените значение на IP-адрес вашего экземпляра EC2 или блоков CIDR IPv4, например.

174.33.0.0/16

Чтобы получить это значение, вы можете либо ssh в свой экземпляр, либо запустить ifconfig или запустить EC2 Manager в браузере и найти значение Частных IP-адресов в деталях вашего экземпляра.

Ответ 3

Дополнительная информация для людей, которые могут столкнуться с подобными проблемами, пытающимися подключиться к RDS или RedShift:

1) Проверьте группы безопасности

Убедитесь, что группа безопасности для экземпляра RDS разрешает доступ из группы безопасности, к которой принадлежит ваш исходный сервер (или его IP-адрес добавлен напрямую, если внешний для AWS). Группу безопасности, на которую вы должны смотреть, - это та, которая указана в атрибутах экземпляра RDS из пользовательского интерфейса консоли RDS (называемая "группа безопасности" ).

ПРИМЕЧАНИЕ. Группы безопасности базы данных могут отличаться от групп безопасности AWS EC2. Если ваш экземпляр RDS находится в классическом/открытом EC2, вы должны проверить раздел "Группа безопасности базы данных" в интерфейсе RDS. Для пользователей VPC группа безопасности будет нормальной группой безопасности VPC (имя sg-xxx будет указано в атрибутах экземпляра RDS).

2) Подтверждение DNS не является проблемой.

Amazon использует разделенный DNS, поэтому внешний вид DNS, внешний для AWS, будет возвращать общедоступный IP-адрес, в то время как внутренний поиск в AWS вернет частный IP-адрес. Если вы подозреваете, что это проблема DNS, подтвердили ли вы, что разные IP-адреса возвращаются из разных зон доступности? Если разные AZ-адреса имеют разные IP-адреса, вам необходимо обратиться в службу поддержки AWS.

3) Подтвердите подключение к сети, установив соединение сокета.

Инструменты, такие как трассировка и трассировка, вероятно, не помогут, поскольку RDS в настоящее время отключает трафик ICMP.

Свяжите тестовый порт, установив соединение сокета с экземпляром RDS на порт 3306 (mysql или 5432 для postgres). Начните с поиска IP-адреса экземпляра RDS и используя telnet или nc:

telnet x.x.x.x 3306
nc -vz x.x.x.x 3306

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

b) Если ваше соединение не выполняется, и вы получаете тайм-аут, пакеты, вероятно, удаляются/игнорируются брандмауэром или пакеты возвращаются по другому сетевому пути. Вы можете подтвердить это, запустив netstat -an | grep SYN (из другого окна/сеанса CLI во время работы и ожидая отключения команды telnet/nc). Соединения в состоянии SYN означают, что вы отправили запрос на соединение, но ничего не получили (SYN_ACK или reject/block). Обычно это означает, что брандмауэр или группа безопасности игнорируют или отбрасывают пакеты.

Убедитесь, что вы не используете iptables или шлюз NAT между вашим хостом и экземпляром RDS. Если вы находитесь в VPC, также убедитесь, что вы разрешаете исходящий/исходящий трафик от исходного узла.

c) Если ваш тест подключения к сокету был успешным, но вы не можете подключиться к клиенту mysql (CLI, workbench, app и т.д.), посмотрите на вывод netstat на посмотрите, в каком состоянии находится соединение (замените xxxx на фактический IP-адрес экземпляра RDS):

netstat -an | grep x.x.x.x

Если вы получили соединение, установленное при использовании telnet или NC, но вы видите состояние "SYN" при использовании клиента mysql, вы можете столкнуться с проблемой MTU.

RDS на момент написания может не поддерживать ICMP-пакеты, используемые для PMTUD (https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD). Это может быть проблемой, если вы пытаетесь получить доступ к RDS или RedShift, что в VPC из классического экземпляра ec2 через ClassicLink. Попробуйте снизить MTU следующим образом, а затем снова проверьте:

sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400

Если работал более низкий MTU, обязательно обратитесь за помощью к службе поддержки AWS за помощью и укажите, что вы видите проблему с MTU при попытке подключиться к вашему экземпляру RDS. Это может произойти, если пакеты TCP завернуты инкапсулированием для туннелирования, что приведет к более дешевому MTU для пакетных данных/полезной нагрузки. Уменьшение MTU на исходном сервере позволяет упакованным пакетам по-прежнему соответствовать лимиту.

Если это не сработало, установите MTU обратно на него по умолчанию и включите поддержку AWS для дальнейшего устранения неполадок.

Ответ 4

В то время как проблема Mark, похоже, имела какое-то отношение к маршрутизации с несколькими AZ и классикой EC2, сегодня я столкнулся с этой же проблемой.

Чтобы исправить это, я изменил группу безопасности, которая была создана автоматически с моим экземпляром RDS, добавив два частных IP-адреса из моего экземпляра EC2.

Это была довольно очевидная проблема, но я новичок в AWS в целом, поэтому, надеюсь, это полезно для других, таких как я.

Ответ 5

По-видимому, мульти-АЗ заправляет все. Поскольку стандартная конфигурация multi-AZ по умолчанию размещала мою базу данных в регионе us-east-1d, а мой экземпляр EC2 находился в регионе us-east-1a, DNS неправильно маршрутизировался. Я заново создал экземпляр RDS как не-мульти-AZ, и сделал его живым в нас-east-1a, и все счастливы.

Если есть какие-либо супер гения в отношении маршрутизации DNS на AWS с возможностями RDS, ELB и multi-AZ, было бы замечательно знать, как это сделать, поскольку это не документировано нигде в Amazon Документация веб-службы.

Ответ 6

У меня была аналогичная проблема сегодня, когда мой экземпляр EC2 внезапно потерял доступ к экземпляру RDS, и Wordpress перестала работать. Группы безопасности были правильными, и я мог даже подключиться к MySQL с консоли на экземпляре EC2, но не с PHP. По какой-то причине перезагрузка сервера EC2 мне помогла.

Ответ 7

В соответствии с Amazon doc, мы должны использовать:

PROMPT> mysql -h <endpoint> -P 3306 -u <mymasteruser> -p

где конечная точка и mymasteruser (имя пользователя) относятся к вашему экземпляру RDS.

Я решил эту проблему с использованием публичного IP-адреса непосредственно (конечной точки) вместо конечной точки (****. us-east-1.rds.amazonaws.com). Вы можете получить открытый IP-адрес, используя "ping" (ping ****. us-east-1.rds.amazonaws.com)