Dodatkowe informacje dla osób, które mogą napotkać podobne problemy, próbując połączyć się z RDS lub RedShift:
1) Sprawdź grupy bezpieczeństwa
Sprawdź, czy grupa zabezpieczeń dla wystąpienia RDS umożliwia dostęp z grupy zabezpieczeń, do której należy serwer źródłowy (lub jej adres IP dodany bezpośrednio, jeśli jest zewnętrzny do AWS). Grupa zabezpieczeń, na którą należy spojrzeć, to ta określona w atrybutach wystąpienia RDS w interfejsie użytkownika konsoli RDS (o nazwie „grupa zabezpieczeń”).
UWAGA :Grupy zabezpieczeń bazy danych mogą różnić się od grup zabezpieczeń AWS EC2. Jeśli twoja instancja RDS jest w klasycznym/publicznym EC2, powinieneś sprawdzić w sekcji "database security group" interfejsu użytkownika RDS. W przypadku użytkowników VPC grupa zabezpieczeń będzie zwykłą grupą zabezpieczeń VPC (nazwa sg-xxx zostanie wyświetlona w atrybutach instancji RDS).
2) Upewnij się, że DNS nie stanowi problemu.
Amazon używa podzielonego DNS, więc wyszukiwanie DNS zewnętrzne do AWS zwróci publiczny adres IP, podczas gdy wyszukiwanie wewnętrzne do AWS zwróci prywatny adres IP. Jeśli podejrzewasz, że jest to problem z DNS, czy potwierdziłeś, że różne adresy IP są zwracane z różnych stref dostępności? Jeśli różne AZ mają różne adresy IP, musisz skontaktować się z pomocą techniczną AWS.
3) Potwierdź połączenie sieciowe, nawiązując połączenie z gniazdem.
Narzędzia takie jak tracepath i traceroute prawdopodobnie nie pomogą, ponieważ RDS obecnie odrzuca ruch ICMP.
Przetestuj łączność portu, próbując nawiązać połączenie gniazda z wystąpieniem RDS na porcie 3306 (mysql lub 5432 dla postgres). Zacznij od znalezienia adresu IP instancji RDS i korzystając z telnet lub nc (należy użyć wewnętrznego/prywatnego adresu IP, jeśli łączysz się z AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Jeśli próba połączenia nie powiedzie się i natychmiast się nie powiedzie, port jest prawdopodobnie zablokowany lub host zdalny nie obsługuje usługi na tym porcie. może być konieczne skorzystanie z pomocy technicznej AWS w celu dalszego rozwiązywania problemów. Jeśli łączysz się spoza AWS, spróbuj najpierw połączyć się z innej instancji wewnątrz AWS (ponieważ zapora może blokować te połączenia).
b) Jeśli połączenie nie powiedzie się i zostanie przekroczony limit czasu, prawdopodobnie pakiety są odrzucane/ignorowane przez zaporę sieciową lub pakiety są zwracane inną ścieżką sieciową. Możesz to potwierdzić, uruchamiając netstat -an | grep SYN (z innej sesji ssh podczas oczekiwania na przekroczenie limitu czasu polecenia telnet/nc).
Połączenia w stanie SYN oznaczają, że wysłałeś żądanie połączenia, ale nie otrzymałeś niczego z powrotem (SYN_ACK lub odrzuć/zablokuj). Zwykle oznacza to, że zapora sieciowa lub grupa bezpieczeństwa ignoruje lub odrzuca pakiety.
Może to być również problem z routingiem NAT lub wieloma ścieżkami z wielu interfejsów. Sprawdź, czy nie używasz iptables ani bramy NAT między hostem a instancją RDS. Jeśli korzystasz z VPC, upewnij się również, że zezwalasz na ruch wychodzący/wychodzący z hosta źródłowego.
c) Jeśli test połączenia z gniazdem zakończył się pomyślnie, ale nie możesz połączyć się z klientem mysql (CLI, warsztat, aplikacja itp.), spójrz na wyjście netstat, aby zobaczyć, w jakim stanie jest połączenie (zamień x.x.x.x na rzeczywisty adres IP instancji RDS):
netstat -an | grep x.x.x.x
Jeśli podczas korzystania z telnetu lub NC nawiązywano połączenie, ale widzisz stan „SYN” podczas korzystania z klienta mysql, być może masz problem z MTU.
RDS, w momencie pisania tego tekstu, może nie obsługiwać pakietów ICMP używanych przez PMTUD (https:/ /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Może to stanowić problem, jeśli próbujesz uzyskać dostęp do RDS lub RedShift w VPC z klasycznej instancji ec2 za pośrednictwem ClassicLink. Spróbuj obniżyć MTU w następujący sposób, a następnie przetestuj ponownie:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Jeśli niższe MTU zadziałało, skontaktuj się z obsługą klienta AWS, aby uzyskać pomoc i wspomnij, że widzisz problem z MTU podczas próby połączenia z instancją RDS. Może się tak zdarzyć, jeśli pakiety TCP są otoczone enkapsulacją w celu tunelowania, co skutkuje niższym MTU użytecznym dla danych pakietowych / ładunku. Obniżenie wartości MTU na serwerze źródłowym pozwala opakowanym pakietom nadal mieścić się poniżej limitu MTU podczas przechodzenia przez bramę tunelowania.
Jeśli to nie zadziałało, ustaw MTU z powrotem na wartość domyślną i włącz obsługę AWS w celu dalszego rozwiązywania problemów.
