Дополнительная информация для людей, которые могут столкнуться подобными проблемами, пытающихся подключиться к 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 или размыкающих (обязательно использовать внутренний/частный IP при подключении внутри АМС):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
а) Если попытка подключения не успешно и немедленно выходит из строя, порт, вероятно, заблокирован или удаленный хост не запускает службу на этом порту. вам может потребоваться задействовать поддержку AWS для дальнейшего устранения неполадок. Если вы подключаетесь извне AWS, попробуйте сначала подключиться к другому экземпляру внутри AWS (поскольку ваш брандмауэр может блокировать эти подключения).
b) Если ваше соединение не увенчалось успехом, и вы получите тайм-аут, пакеты, вероятно, будут удалены/проигнорированы брандмауэром или пакеты возвращаются на другом сетевом пути. Вы можете подтвердить это, запустив netstat -an | grep SYN (из другого сеанса ssh, ожидая команды telnet/nc для таймаута).
Соединения в состоянии SYN означают, что вы отправили запрос на соединение, но ничего не получили (SYN_ACK или reject/block). Обычно это означает, что брандмауэр или группа безопасности игнорируют или удаляют пакеты.
Это также может быть проблема с маршрутизацией NAT или несколькими путями из нескольких интерфейсов. Убедитесь, что вы не используете iptables или шлюз NAT между вашим хостом и экземпляром RDS. Если вы находитесь в VPC, также убедитесь, что вы разрешаете исходящий/исходящий трафик от исходного узла.
с) Если тестовое соединение сокет был успешным, но вы не можете связаться с клиентом MySQL (CLI, верстак, приложение и т.д.), взгляните на выходе NetStat, чтобы увидеть, в каком состоянии соединение в (заменить хххх с реальным 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 при прохождении через туннельный шлюз.
Если это не сработало, установите MTU на его значение по умолчанию и включите поддержку AWS для дальнейшего устранения неполадок.