EC2 인스턴스 연결 문제 진단: 보안 그룹 및 네트워크 ACL

Amazon Elastic Compute Cloud (EC2) 인스턴스에 연결하는 것은 기본적인 작업이지만, 연결 실패는 AWS 사용자에게 가장 흔한 문제 해결 시나리오 중 하나입니다. 인스턴스가 정상적으로 실행 중인 것처럼 보이지만 SSH, RDP 또는 애플리케이션 트래픽을 통해 접근할 수 없을 때, 문제는 거의 항상 주변 네트워크 보안 계층에 있습니다. 이 포괄적인 가이드는 세 가지 중요한 네트워크 제어 지점인 보안 그룹(SG), 네트워크 접근 제어 목록(NACL) 및 VPC 라우팅 테이블에 초점을 맞춰 연결 문제를 체계적으로 진단하고 해결하는 방법을 설명합니다.

이러한 제어의 계층 구조와 기능을 이해하는 것이 핵심입니다. 보안 그룹은 인스턴스 수준의 상태 저장 방화벽 역할을 하며, NACL은 서브넷 수준의 상태 비저장 방화벽 역할을 합니다. 이 구성 요소 중 하나라도 잘못 구성되거나 라우팅 경로가 올바르지 않으면 예상된 트래픽이 즉시 차단되어 실망스러운 연결 시간 초과가 발생합니다.

EC2 연결 제어의 세 가지 기둥

특정 구성으로 들어가기 전에 각 구성 요소가 EC2 인스턴스로 가는 트래픽 경로에서 어떤 역할을 하는지 이해하는 것이 중요합니다.

1. 라우팅 테이블: 대상 IP 주소를 기반으로 네트워크 트래픽을 어디로 보낼지 결정합니다. 인터넷이나 클라이언트 IP로 향하는 트래픽이 올바른 서브넷 게이트웨이에 도달하지 못하면 연결이 실패합니다.
2. 네트워크 ACL(NACL): 전체 서브넷에 규칙을 적용합니다. 상태 비저장(stateless)이므로 들어오는 트래픽과 나가는 트래픽 모두 명시적으로 허용해야 합니다. 규칙은 가장 낮은 번호부터 가장 높은 번호 순서로 처리되며, 첫 번째 일치하는 규칙에서 중지됩니다.
3. 보안 그룹(SG): EC2 인스턴스의 탄력적 네트워크 인터페이스(ENI)에 직접 규칙을 적용합니다. 상태 저장(stateful)이므로 들어오는 트래픽을 허용하면 해당 나가는 트래픽은 자동으로 허용됩니다.

1단계: VPC 라우팅 테이블 확인

첫 번째 진단 확인은 EC2 인스턴스가 있는 서브넷에 트래픽이 도달할 경로가 있는지 항상 확인해야 합니다.

들어오는 라우팅 확인

퍼블릭 인터넷에서 인스턴스에 접근 가능한 경우(예: SSH/RDP 사용 시):

• 목표: 인스턴스가 포함된 서브넷이 0.0.0.0/0 (또는 특정 클라이언트 IP 범위)에서 발생하는 트래픽에 대해 인터넷 게이트웨이(IGW)로 가는 경로를 가지고 있는지 확인합니다.
• 작업: VPC 콘솔로 이동하여 라우팅 테이블을 선택하고 인스턴스의 서브넷과 연결된 라우팅 테이블을 검토합니다. 다음과 같은 항목을 찾습니다.
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

나가는 라우팅 확인(상태 저장 문제의 경우)

보안 그룹은 상태 저장 방식이지만, 특히 반환 트래픽이나 외부 서비스에 연결을 시작하는 인스턴스의 경우 나가는 경로를 확인하는 것이 중요합니다.

• 작업: 인스턴스가 프라이빗 서브넷에 있는 경우, 인터넷에 접속하기 위해 NAT 게이트웨이 또는 NAT 인스턴스로 가는 경로가 있는지 확인합니다. 퍼블릭 서브넷에 있는 경우 0.0.0.0/0을 IGW로 라우팅해야 합니다.

팁: 동일한 VPC 내의 다른 서브넷에서 인스턴스로 핑을 할 수 없다면, 트래픽을 잘못된 로컬 게이트웨이나 VPC 피어링 연결로 보내는 잘못 구성된 라우팅 테이블이 거의 확실한 문제입니다.

2단계: 네트워크 ACL(서브넷 수준) 검사

NACL은 서브넷 수준에서 작동하고 상태 비저장이기 때문에 종종 간과됩니다. 일반적인 오류는 들어오는 트래픽은 허용하지만 반환 나가는 트래픽을 명시적으로 허용하는 것을 잊는 것입니다.

들어오는 규칙 확인

들어오는 연결 시도(예: 포트 22의 SSH)의 경우:

1. 인스턴스의 서브넷과 연결된 NACL을 식별합니다.
2. 들어오는 규칙을 검토합니다.
3. 사용 중인 특정 포트와 프로토콜을 허용하는 규칙이 있는지 확인합니다(예: 규칙 100: 유형: SSH(22), 프로토콜: TCP, 소스: 0.0.0.0/0).

나가는 규칙 확인(상태 비저장 함정)

대부분의 NACL 연결 문제가 발생하는 부분입니다.

1. 나가는 규칙을 검토합니다.
2. 들어오는 SSH(포트 22)를 허용했다면, 인스턴스는 클라이언트로 높은 포트(임시 포트) 범위, 일반적으로 1024-65535로 트래픽을 다시 보내야 합니다.
3. 작업: 관련 대상 포트 범위(클라이언트가 연결을 시작하는 경우 종종 1024-65535)로 트래픽을 허용하는 나가는 규칙이 있는지 확인합니다.

들어오는 SSH 액세스를 위한 예시 NACL 규칙 세트:

경고: NACL은 숫자를 기준으로 규칙을 평가합니다. 규칙 90이 DENY ALL이면, 후속 규칙 100 ALLOW SSH는 절대 처리되지 않습니다. 명시적인 허용 규칙이 광범위한 거부 규칙보다 낮은 번호를 갖도록 하거나, 최종 암시적 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 연결이 실패하면 다음 진단 순서를 따르십시오.

1. 라우팅 테이블 확인: 트래픽 경로(들어오는 및 나가는)가 올바른 서브넷 게이트웨이(IGW/VPC 피어링/NAT)에 도달할 수 있습니까?
2. NACL 확인(상태 비저장): 트래픽이 특정 들어오는 포트에서 명시적으로 허용되고 반환 트래픽(종종 높은 임시 포트)이 나가는 방향에서 명시적으로 허용됩니까?
3. 보안 그룹 확인(상태 저장): 트래픽이 특정 들어오는 포트에서 명시적으로 허용됩니까? (나가는 트래픽은 일반적으로 열려 있어야 합니다).

광범위한 네트워크 계층(라우팅)에서 서브넷 수준(NACL)으로, 그리고 마지막으로 인스턴스 수준(SG)으로 체계적으로 이동함으로써 상태 비저장 필터링, 상태 저장 필터링 또는 라우팅 실패인지 여부를 신속하게 격리할 수 있습니다.