Nie można połączyć się z instancją RDS z instancji EC2

Miałem podobny problem, gdy uruchomiłem nową instancję EC2, ale nie zmieniłem ustawienia w grupie zabezpieczeń RDS przychodzącego adresu IP pozwalającego połączyć się z portem 3306 mojej instancji RDS.

Bit mylący był opcją w pulpicie RDS, nazywaną grupami zabezpieczeń. Nie potrzebujesz go do rozwiązania problemu.

To czego naprawdę potrzebujesz to:

• przejdź do listy instancji RDS
• Kliknij instancję, którą próbujesz połączyć
• Kliknij zasady grupy zabezpieczeń sekcja

To powinno otworzyć nową kartę lub okno przeglądarki ze szczegółami grupy zabezpieczeń. Znajdź kilka kart w dolnej części, wybierz kartę Inbound rules i kliknij przycisk Edytuj.

Zmień wartość na adres IP Twojej instancji EC2 lub bloków CIDR IPv4, np.

174.33.0.0/16

Aby uzyskać tę wartość, możesz użyć ssh do swojej instancji i uruchomić IP addr lub uruchomić Menedżera EC2 w browser and locate value of Private IPs in your instance details.

Dodatkowe informacje dla osób, które mogą napotkać podobne problemy, próbując połączyć się z RDS lub RedShift:

1) Sprawdź grupy zabezpieczeń

Zweryfikuj grupę zabezpieczeń dla instancji RDS, która zezwala na 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ą powinieneś patrzeć, to ta określona w atrybutach wystąpienia RDS z interfejsu konsoli RDS (o nazwie " bezpieczeństwo Grupa").

UWAGA: grupy zabezpieczeń baz danych mogą różnić się od grup zabezpieczeń AWS EC2. Jeśli twoja instancja RDS znajduje się w klasycznym/publicznym EC2, powinieneś sprawdzić w sekcji "Grupa bezpieczeństwa bazy danych" interfejsu RDS. Dla użytkowników VPC grupa zabezpieczeń będzie normalną grupą zabezpieczeń VPC(NAZWA sg-xxx będzie wymieniona w atrybutach instancji RDS).

2) Potwierdź, że DNS nie jest problemem.

Amazon używa podzielonego DNS, więc odnośnik DNS zewnętrzny do AWS zwróci publiczne IP podczas wyszukiwania wewnętrznego AWS zwróci prywatne IP. Jeśli podejrzewasz, że jest to problem DNS, czy potwierdziłeś, że różne adresy IP są zwracane z różnych stref dostępności? Jeśli różne AZs otrzymają różne IP, musisz skontaktować się z Pomocą techniczną AWS.

3) Potwierdź łączność sieciową, ustanawiając połączenie z gniazdem.

Narzędzia takie jak tracepath i traceroute prawdopodobnie nie pomogą, ponieważ RDS obecnie zmniejsza ruch ICMP.

Przetestuj połączenie z portem, próbując aby nawiązać połączenie gniazda z instancją RDS na porcie 3306 (mysql lub 5432 dla postgres). Zacznij od znalezienia adresu IP instancji RDS i skorzystaj z telnetu lub nc:

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 zdalny host nie uruchamia usługi na tym porcie. może być konieczne zaangażowanie pomocy AWS w celu dalszego rozwiązywania problemów. Jeśli łączysz się spoza AWS, spróbuj połączyć się z innej instancji wewnątrz AWS najpierw (ponieważ zapora może blokować te połączenia).

B) Jeśli Twoje połączenie nie powiedzie się i masz limit czasu, pakiety są prawdopodobnie ignorowane przez zaporę lub pakiety wracają na inną ścieżkę sieciową. Możesz to potwierdzić uruchamiając netstat -an | grep SYN (z innego okna/sesji CLI podczas uruchamiania i oczekiwania na timeout polecenia telnet/nc). Połączenia w stanie SYN oznaczają, że wysłano żądanie połączenia, ale nie otrzymano niczego back (SYN_ACK lub reject/block). Zazwyczaj oznacza to, że zapora lub grupa zabezpieczeń ignoruje lub upuszcza Pakiety.

Sprawdź, czy nie używasz iptables ani bramy NAT pomiędzy Twoim hostem a instancją RDS. Jeśli korzystasz z VPC, upewnij się, że zezwalasz na ruch wychodzący/wychodzący z hosta źródłowego.

C) Jeśli test połączenia z gniazdem powiódł się, ale nie można połączyć się z klientem mysql (CLI, workbench, app, itp.), spójrz na wyjście netstat do zobacz 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 nawiązywane jest połączenie podczas korzystania z telnet lub NC, ale widzisz stan "SYN" podczas korzystania z klienta mysql, możesz mieć problem z MTU.

RDS, w momencie pisania tego tekstu, może nie obsługiwać pakietów ICMP używanych dla PMTUD ( https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). może to być problem, jeśli próbujesz uzyskać dostęp do RDS lub RedShift, który jest w VPC z klasycznej instancji ec2 za pośrednictwem ClassicLink. Spróbuj obniżyć MTU za pomocą następującego polecenia, 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ższy MTU zadziałał, pamiętaj, aby skontaktować się z Działem obsługi klienta AWS w celu uzyskania pomocy i wspomnieć, że widzisz problem MTU podczas próby połączenia z instancją RDS. Może się to zdarzyć, jeśli pakiety TCP są owinięte enkapsulacją do tunelowania, co skutkuje niższym użytecznym MTU dla danych pakietów / ładunku. Obniżenie MTU na serwerze źródłowym pozwala owiniętym pakietom na zmieszczenie się poniżej limitu.

Jeśli nie zadziałało, Ustaw swój MTU z powrotem na domyślny i włącz obsługę AWS w celu dalszego rozwiązywania problemów.

Podczas gdy problem Marka wydawał się mieć coś wspólnego z multi-AZ routing & EC2 classic, natknąłem się na ten sam problem dzisiaj.

Aby to naprawić, zmodyfikowałem grupę zabezpieczeń, która została utworzona automatycznie z moją instancją RDS, dodając dwa prywatne adresy IP z mojej instancji EC2.

To był dość oczywisty problem, ale ogólnie jestem nowy w AWS, więc mam nadzieję, że jest to przydatne dla innych takich jak ja.

Najwyraźniej multi-AZ wszystko spieprza. Ponieważ domyślna konfiguracja multi-AZ umieściła moją bazę danych w regionie us-east-1D, a moja instancja EC2 znajdowała się w regionie us-east-1A, DNS Nie trasował poprawnie. Odtworzyłem instancję RDS jako non-multi-AZ i zrobiłem ją w us-east-1A, i wszystko jest szczęśliwe.

Jeśli istnieją jacyś Super geniusze w odniesieniu do routingu DNS na AWS z możliwościami RDS, ELB i multi-AZ, byłoby całkiem fajnie wiedzieć, jak to zrobić, ponieważ nie jest to udokumentowane w dowolnym miejscu w dokumentacji Amazon Web Service.

Miałem podobny problem dzisiaj, gdy moja instancja EC2 nagle straciła dostęp do instancji RDS i Wordpress przestał działać. Grupy zabezpieczeń były poprawne i mogłem nawet połączyć się z MySQL z konsoli na instancji EC2, ale nie z PHP. Z jakiegoś powodu ponowne uruchomienie serwera EC2 mi pomogło.

Po 3 dniach zmagań w końcu odkryłem, Dlaczego mój nie był podłączony ...

Dodaj regułę wychodzącą dla instancji EC2 dla portu 3306 i reguł przychodzących na serwerze RDS na porcie 3306. Wartość przychodząca powinna być zabezpieczeniem instancji EC2

Przykład:

• Twoja grupa bezpieczeństwa EC2 to-sg. ec2
• a RDS security group to-sg.rds

Więc przejdź do edycji reguł wychodzących sg. ec2 i dodaj Niestandardowy TCP na porcie 3306 i destination do 0.0.0.0/0

Następnie przejdź do edycji reguły przychodzącej sg.rds i dodać regułę przychodzącą na porcie 3306 i źródło jako sg. ec2

Zgodnie z Amazon doc , powinniśmy użyć:

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

Gdzie endpoint i mymasteruser (nazwa użytkownika) pochodzą z Twojej instancji RDS.

Rozwiązałem ten problem używając publicznego adresu IP bezpośrednio (punktu końcowego) zamiast punktu końcowego ( * * * * . us-east-1.rds.amazonaws.com). możesz uzyskać publiczny adres ip za pomocą polecenia "ping" (ping****. us-east-1.rds.amazonaws.com)