VPC 외부에서 RDS 인스턴스에 연결할 수 없습니다 (ERROR 2003 (HY000)은 MySQL 서버에 연결할 수 없음)


12

VPC를 만들고 그 안에 RDS 인스턴스를 만들었습니다. RDS 인스턴스는 공개적으로 액세스 할 수 있으며 설정은 다음과 같습니다.

RDS 설정

RDS 인스턴스에 연결된 보안 그룹은 모든 트래픽을 허용합니다.

보안 그룹 설정

모든 네트워크 ACL은 모든 트래픽을 허용합니다. 그러나 VPC 외부의 시스템에서 인스턴스에 액세스 할 수 없습니다. 다음과 같은 오류가 발생합니다.

    root@vps151014:~# mysql -h mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com -P 3306 -u skullberry -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com' (110)

VPC 내부의 EC2에서 동일한 명령을 실행하면 연결할 수 있습니다. 방화벽없이 여러 컴퓨터에서 연결을 시도했습니다 (예 : 포트 3306이 열려 있음).

분명히 뭔가 빠졌지 만 모든 것이 올바르게 구성된 것 같습니다. 무엇이 문제 일 수 있습니까?


1
(가) (110)오류 메시지 수단 "연결 시간이 초과되었습니다"그래서 확실히 이것은 IP 연결 문제입니다. RDS 인스턴스는 두 개의 서브넷과 연결되어 있습니다. VPC 콘솔에서이 두 서브넷의 기본 경로는 무엇입니까? "igw-xxxxxxxx"입니까, "i-xxxxxxxx"입니까?
Michael-sqlbot

두 서브넷 모두 VPC 의 기본 라우팅 테이블 과 암시 적으로 연결됩니다 .
dazedviper

1
모든 아웃 바운드 트래픽을 VPC의 인터넷 게이트웨이로 라우팅하는 사용자 지정 라우팅 테이블에 두 서브넷을 명시 적으로 연결하면 아무런 차이가 없습니다.
dazedviper

1
글쎄. "igw"에 대한 기본 경로는 가장 유실 된 누락 된 조각처럼 보였으며이 작업을 수행하는 데 필요한 경우가 있습니다. 서브넷 구성을 적절하게 변경 한 후 백그라운드에서 VPC를 다시 구성 할 수있는 충분한 시간이 있다고 가정하면 아이디어가 없습니다.
Michael-sqlbot

2
아, 모든 IP 주소에 필요한 블록은 0.0.0.0/0입니다. 답변을 게시하겠습니다.
Michael-sqlbot

답변:


20

VPC의 RDS 인스턴스가 "공개"(인터넷) 액세스 가능하도록하려면 연결된 모든 서브넷이 VPC의 "개인"이 아닌 "공용"이어야합니다.

퍼블릭 서브넷은 기본적으로 인터넷 게이트웨이 개체 (igw-xxxxxxxx)가 "인터넷"또는 최소한 액세스해야하는 인터넷 대상에 대한 경로로 사용되는 서브넷으로 정의됩니다. 일반적으로 주소는 0.0.0.0/0입니다. 퍼블릭 서브넷은 연결된 퍼블릭 IP 주소가있는 인스턴스 (RDS 포함)에 사용해야하며 퍼블릭 IP 주소가없는 인스턴스에는 사용되지 않아야합니다. 프라이빗 주소는 변환없이 인터넷에서 작동하지 않기 때문입니다.

반면 프라이빗 서브넷에는 라우팅 테이블이 다른 EC2 인스턴스 (일반적으로 NAT 인스턴스)를 통해 인터넷 대상에 도달하도록 구성되어 있습니다. 이는 해당 서브넷과 연결된 VPC 라우팅 테이블에 "igw"가 아니라 i-xxxxxxxx로 표시됩니다. 해당 시스템 (실제로 자신이 라우팅 대상 역할을하는 시스템과 다른 서브넷에 있음)은 변환기 역할을하며 사설 IP 전용 인스턴스는 NAT 시스템의 공개를 사용하여 아웃 바운드 인터넷 요청을 투명하게 만들 수 있습니다. 인터넷 요구에 맞는 IP. 퍼블릭 IP 주소를 가진 인스턴스는 프라이빗 서브넷에 연결된 경우 인터넷과 올바르게 상호 작용할 수 없습니다.

특정 경우, 여기서 RDS 인스턴스와 연결된 서브넷은 서브넷에 기본 경로가 전혀 없기 때문에 실제로 프라이빗 또는 퍼블릭 서브넷으로 분류 할 수있는 것으로 구성되지 않았습니다. "igw"개체를 통해 기본 경로를 추가하거나 OP와 마찬가지로 연결이 필요한 인터넷 IP 주소에 고정 경로를 서브넷의 VPC 경로 테이블에 추가하면 연결 문제가 해결됩니다.

그러나 ... 비슷한 문제가 발생하면 변경 사항이 합리적으로 발생할 수 있기 때문에 서브넷에서 이미 올바르게 작동하는 것이 없으면 라우팅 테이블을 변경하거나 새 라우팅 테이블을 작성하고 서브넷을 연결할 수 없습니다. 기존 연결이 끊어 질 것으로 예상됩니다. 이 경우 올바른 경로 테이블 항목을 사용하여 다른 서브넷의 인스턴스를 프로비저닝하는 것이 올바른 과정입니다.

VPC를 설정할 때 서브넷 역할을 명확하게 정의하고 VPC를 처음 시운전 할 때 필요한 경로를 완전히 제공하는 것이 이상적입니다. 전체 VPC "LAN"은 소프트웨어 정의 네트워크라는 점도 기억해야합니다. 물리적 네트워크와 달리 라우터가 병목 현상이 발생하고 트래픽이 많은 시스템을 동일한 서브넷에 배치하는 것이 현명한 경우가 많습니다. 트래픽 교차 서브넷은 VPC에서 성능상의 단점이 없습니다. 머신은 머신의 IP 주소 요구에 적합한 서브넷 (퍼블릭 주소, 퍼블릭 서브넷)에 배치해야합니다. 공개 주소, 개인 서브넷이 없습니다.

VPC에서 프라이빗 / 퍼블릭 서브넷의 물류에 대한 자세한 내용은 VPC에서 프라이빗 서브넷이 필요한 이유 (스택 오버플로)에서 확인할 수 있습니다.


2

이미 훌륭한 답변이 있지만 "공개적으로 액세스 가능"옵션을 선택하면 AWS가 퍼블릭 서브넷을 생성합니다. 오히려 문제는 기본 VPC 보안 그룹이었습니다. 보안 그룹이 아닌 네트워크 ACL 규칙 을보고있었습니다 . RDS에서 "공개적으로 액세스 가능"옵션을 선택하면 보안 그룹이 추가되지만 인바운드 규칙은 자동으로 추가되지 않습니다.

RDS를 클릭하고 보안 그룹을 식별하고 클릭하십시오. 그런 다음 "인바운드 규칙"에서 포트 3306을 추가하고 연결 IPV4 주소 xxxx / 32 (또는 전체 인터넷을 연결하려는 경우 0.0.0.0/32-추가하지만주의해야 함)를 추가하십시오.


0

또한 연결된 네트워크가 포트 3306의 다른 서버에 대한 연결을 차단하지 않는지 확인하십시오. 회사 네트워크에 연결했을 때의 경우입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.