EC2 인스턴스 연결 문제 진단: 보안 그룹 및 네트워크 ACL
라우팅 테이블, 상태 비저장 네트워크 ACL, 상태 저장 보안 그룹을 올바른 순서로 확인하여 EC2 연결 문제를 진단합니다.
EC2 인스턴스 연결 문제 진단: 보안 그룹 및 네트워크 ACL
EC2 인스턴스가 실행 중이지만 SSH, RDP 또는 애플리케이션 트래픽이 시간 초과되는 경우, 일반적으로 인스턴스 주변의 네트워크 경로에 문제가 있습니다. EC2 연결 문제를 진단하려면 먼저 라우팅 테이블을 확인한 다음 서브넷 네트워크 ACL, 마지막으로 인스턴스 보안 그룹을 확인하세요.
이러한 제어의 계층 구조와 기능을 이해하는 것이 중요합니다. 보안 그룹은 인스턴스 수준의 상태 저장 방화벽 역할을 하는 반면, NACL은 상태 비저장 서브넷 수준 방화벽 역할을 합니다. 이러한 구성 요소 중 하나라도 잘못 구성되거나 라우팅 경로가 잘못되면 예상 트래픽이 즉시 차단되어 연결 시간 초과가 발생할 수 있습니다.
EC2 연결 제어의 세 가지 핵심 요소
특정 구성을 살펴보기 전에 EC2 인스턴스로의 트래픽 경로에서 각 구성 요소가 수행하는 역할을 이해하는 것이 중요합니다.
- 라우팅 테이블: 대상 IP 주소를 기반으로 네트워크 트래픽이 전달되는 위치를 결정합니다. 인터넷 또는 클라이언트 IP로 향하는 트래픽이 올바른 서브넷 게이트웨이에 도달할 수 없으면 연결이 실패합니다.
- 네트워크 ACL(NACL): 전체 서브넷에 규칙을 적용합니다. 상태 비저장이므로 인바운드 및 아웃바운드 트래픽을 모두 명시적으로 허용해야 합니다. 가장 낮은 번호의 규칙부터 가장 높은 번호의 규칙 순서대로 규칙을 처리하며, 첫 번째 일치에서 중지됩니다.
- 보안 그룹(SG): EC2 인스턴스의 탄력적 네트워크 인터페이스(ENI)에 직접 규칙을 적용합니다. 상태 저장이므로 인바운드 트래픽을 허용하면 아웃바운드 반환 트래픽이 자동으로 허용됩니다.
1단계: VPC 라우팅 테이블 확인
첫 번째 진단 확인은 트래픽이 EC2 인스턴스가 있는 서브넷에 도달할 수 있는 경로가 있는지 항상 확인해야 합니다.
인바운드 라우팅 확인
퍼블릭 인터넷에서 연결할 수 있는 인스턴스(예: SSH/RDP)의 경우:
- 목표: 퍼블릭 인스턴스가 포함된 서브넷에 인터넷 게이트웨이(IGW) 에 대한 기본 경로가 있는지 확인합니다.
- 작업: VPC 콘솔로 이동하여 라우팅 테이블을 선택하고 인스턴스의 서브넷과 연결된 라우팅 테이블을 검사합니다. 다음과 같은 항목을 찾으세요.
대상: 0.0.0.0/0 | 대상: igw-xxxxxxxx
아웃바운드 라우팅 확인(상태 저장 문제의 경우)
SG는 상태 저장이지만, 특히 반환 트래픽이나 외부 서비스에 대한 연결을 시작하는 인스턴스의 경우 아웃바운드 경로를 확인하는 것이 중요합니다.
- 작업: 인스턴스가 프라이빗 서브넷에 있는 경우 인터넷에 도달할 수 있도록 NAT 게이트웨이 또는 NAT 인스턴스에 대한 경로가 있는지 확인하세요. 퍼블릭 서브넷에 있는 경우
0.0.0.0/0을 IGW로 라우팅해야 합니다.
팁: 동일한 VPC 내 서브넷 간의 트래픽은 일반적으로 암시적
local경로를 사용합니다. 해당 트래픽이 실패하면 라우팅 테이블을 탓하기 전에 보안 그룹, NACL, 호스트 방화벽 및 대상이 ICMP를 허용하는지 확인하세요.
2단계: 네트워크 ACL 검사(서브넷 수준)
NACL은 서브넷 수준에서 작동하고 상태 비저장이기 때문에 종종 간과됩니다. 일반적인 오류는 인바운드 트래픽을 허용하지만 반환 아웃바운드 트래픽을 명시적으로 허용하는 것을 잊는 것입니다.
인바운드 규칙 확인
인바운드 연결 시도(예: 포트 22의 SSH)의 경우:
- 인스턴스의 서브넷과 연결된 NACL을 식별합니다.
- 인바운드 규칙을 검사합니다.
- 사용 중인 특정 포트와 프로토콜을 허용하는 규칙이 있는지 확인합니다(예: 규칙 100: 유형: SSH(22), 프로토콜: TCP, 소스:
0.0.0.0/0).
아웃바운드 규칙 확인(상태 비저장 함정)
이것은 대부분의 NACL 연결 문제가 발생하는 곳입니다.
- 아웃바운드 규칙을 검사합니다.
- 인바운드 SSH(포트 22)를 허용한 경우 인스턴스는 일반적으로 1024-65535 범위의 상위 포트(임시 포트) 를 통해 클라이언트로 트래픽을 다시 보내야 합니다.
- 작업: 아웃바운드 규칙이 관련 대상 포트 범위(클라이언트가 연결을 시작하는 경우 종종
1024-65535)로의 트래픽을 명시적으로 허용하는지 확인합니다.
인바운드 SSH 액세스를 위한 NACL 규칙 예:
인바운드 규칙:
| 규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 소스 | 허용/거부 |
|---|---|---|---|---|---|
| 100 | SSH | TCP | 22 | 클라이언트 IP/CIDR | ALLOW |
| * | * | * | * | * | DENY (기본값) |
아웃바운드 규칙:
| 규칙 번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/거부 |
|---|---|---|---|---|---|
| 100 | 사용자 지정 TCP | TCP | 1024-65535 | 클라이언트 IP/CIDR | ALLOW |
| * | * | * | * | * | DENY (기본값) |
경고: NACL은 규칙을 숫자 순서로 평가합니다. 규칙 90이
DENY ALL인 경우, 후속 규칙 100ALLOW SSH는 적용되지 않습니다. 명시적 ALLOW 규칙이 광범위한 DENY 규칙보다 낮은 번호를 가지거나 최종 암시적 DENY ALL 규칙에 의존해야 합니다.
3단계: 보안 그룹 감사(인스턴스 수준)
보안 그룹은 인스턴스에 직접 적용되는 최종 방어선입니다. 상태 저장이므로 관리하기가 더 쉽습니다.
인바운드 규칙 확인
EC2 인스턴스에 연결된 SG가 예상 소스의 필수 포트에서 트래픽을 허용하는지 확인합니다.
- SSH(Linux)의 경우: 공용 IP 또는
0.0.0.0/0(필요한 경우)에서 TCP 포트 22를 허용하는 인바운드 규칙. - RDP(Windows)의 경우: 공용 IP 또는
0.0.0.0/0에서 TCP 포트 3389를 허용하는 인바운드 규칙. - 웹 트래픽의 경우:
0.0.0.0/0에서 TCP 포트 80 및/또는 443을 허용하는 인바운드 규칙.
아웃바운드 규칙 확인(일반적으로 기본값)
SG는 상태 저장이므로 아웃바운드 규칙은 일반적으로 모든 트래픽 허용(모든 포트에서 0.0.0.0/0)으로 구성됩니다. 아웃바운드 규칙을 사용자 지정한 경우 클라이언트의 임시 포트 범위로의 응답을 허용하는지 확인하세요.
모범 사례: 엄격한 보안 요구 사항이 없는 한 보안 그룹의 아웃바운드 규칙을 기본값인 모든 대상에 대한 모든 트래픽 허용으로 설정해 두세요. 이렇게 하면 NACL 또는 라우팅 테이블 문제를 분리할 수 있으므로 문제 해결이 훨씬 간단해집니다.
연결 체크리스트
EC2 연결이 실패하면 다음 진단 순서를 따르세요.
- 라우팅 테이블 확인: 트래픽 경로(인바운드 및 아웃바운드)가 올바른 서브넷 게이트웨이(IGW/VPC 피어링/NAT)에 도달할 수 있습니까?
- NACL 확인(상태 비저장): 트래픽이 특정 인바운드 포트에서 명시적으로 허용되고 반환 트래픽(종종 상위 임시 포트)이 아웃바운드에서 명시적으로 허용됩니까?
- 보안 그룹 확인(상태 저장): 트래픽이 특정 인바운드 포트에서 명시적으로 허용됩니까? (아웃바운드는 일반적으로 열려 있어야 합니다.)
광범위한 네트워크 계층(라우팅)에서 서브넷 수준(NACL)으로, 마지막으로 인스턴스 수준(SG)으로 체계적으로 이동하면 차단 메커니즘이 상태 비저장 필터링, 상태 저장 필터링 또는 라우팅 실패인지 신속하게 격리할 수 있습니다.