Допълнителна информация за хора, които могат да срещнат подобни проблеми, опитвайки се да се свържат с 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) Потвърдете мрежовата свързаност, като установите връзка чрез сокет.
Инструменти като tracepath и traceroute вероятно няма да помогнат, тъй като RDS в момента пропуска ICMP трафик.
Тествайте връзката на порта, като се опитате да установите връзка на сокет към RDS екземпляра на порт 3306 (mysql или 5432 за postgres). Започнете с намиране на IP на екземпляра на RDS и използване на telnet или nc (не забравяйте да използвате вътрешния/личен IP адрес, ако се свързвате от AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
а) Ако опитът ви за свързване не е успешен и веднага се провали, портът вероятно е блокиран или отдалеченият хост не изпълнява услуга на този порт. може да се наложи да ангажирате поддръжката на AWS за по-нататъшно отстраняване на неизправности. Ако се свързвате извън AWS, опитайте първо да се свържете от друг екземпляр в AWS (тъй като вашата защитна стена може да блокира тези връзки).
б) Ако връзката ви не е успешна и получите изчакване, пакетите вероятно се изпускат/игнорират от защитна стена или пакетите се връщат по различен мрежов път. Можете да потвърдите това, като изпълните netstat -an | grep SYN (от друга ssh сесия, докато изчаквате командата telnet/nc да изтече).
Връзките в състояние SYN означават, че сте изпратили заявка за връзка, но не сте получили нищо обратно (SYN_ACK или отказ/блокиране). Обикновено това означава, че защитна стена или група за сигурност игнорира или изпуска пакети.
Може също да е проблем с NAT маршрутизиране или множество пътища от множество интерфейси. Проверете дали не използвате iptables или NAT шлюз между вашия хост и RDS екземпляра. Ако сте във VPC, също така се уверете, че разрешавате изходящ/изходящ трафик от изходния хост.
в) Ако вашият тест за свързване на сокет е бил успешен, но не можете да се свържете с mysql клиент (CLI, работна маса, приложение и т.н.), погледнете изхода на netstat, за да видите в какво състояние е връзката (заменете x.x.x.x с действителен 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 за по-нататъшно отстраняване на неизправности.
