[AWS] Inbound Traffic 심층 분석: 데이터 패킷의 여정 (A-Z)

Inbound Traffic 심층 분석: 데이터 패킷의 여정 (A-Z)

사용자가 브라우저에 웹사이트 주소를 입력했을 때, 데이터 패킷이 어떤 경로와 검증 절차를 거쳐 웹 서버에 도달하는지 단계별로 상세히 추적해 보겠습니다.

Step 1: DNS 조회 (사용자 환경)

• 역할: 도메인 이름을 IP 주소로 변환합니다.
• 상세 설명: 사용자가 브라우저에 www.example.com을 입력하면, 사용자의 컴퓨터는 DNS(Domain Name System) 서버에 이 도메인에 해당하는 IP 주소를 물어봅니다. DNS 서버는 미리 설정된 레코드(예: AWS Route 53의 A 레코드)를 찾아 웹 서버 EC2 인스턴스에 연결된 공인 IP 주소(예: 52.78.1.1)를 반환합니다. 이 과정은 아직 AWS VPC 외부에서 일어납니다.

Step 2: 인터넷 경유 및 AWS 네트워크 도착

• 역할: 데이터 패킷을 목적지 IP 주소로 전송합니다.
• 상세 설명: 사용자의 브라우저는 이제 목적지 공인 IP 주소를 알고 있으므로, HTTP 요청이 담긴 데이터 패킷을 생성하여 인터넷을 통해 AWS 네트워크의 경계(Edge)로 전송합니다.

Step 3: Internet Gateway (IGW) - VPC의 정문

• 역할: VPC와 인터넷 간의 통신을 중개하고, 주소를 변환합니다.
• 상세 설명: 패킷은 my-vpc에 연결된 my-igw에 도착합니다. IGW는 여기서 매우 중요한 역할인 1:1 NAT(Network Address Translation)를 수행합니다. 패킷의 목적지 주소인 공인 IP(52.78.1.1)를 웹 서버 EC2 인스턴스가 실제로 가지고 있는 사설 IP(10.0.1.100)로 변환합니다. 이제 패킷은 VPC 내부에서 통용되는 주소를 갖게 됩니다.

Step 4: VPC 암시적 라우터 (Implicit Router)의 경로 결정

• 역할: 패킷이 가야 할 서브넷을 결정합니다.
• 상세 설명: VPC에는 우리가 직접 설정하지 않는, AWS가 관리하는 고가용성의 암시적 라우터가 내장되어 있습니다. 이 라우터는 이제 사설 IP( 10.0.1.100)를 목적지로 하는 패킷을 받습니다. 라우터는 VPC에 정의된 모든 서브넷의 IP 대역을 알고 있으므로, 10.0.1.100 주소가 my-public-subnet-a(10.0.1.0/24)에 속한다는 것을 인지하고 해당 서브넷으로 패킷을 전달합니다. 이 과정에서는 모든 라우팅 테이블에 기본적으로 존재하는 local 경로가 사용됩니다.
  

Step 5: 네트워크 ACL (NACL) - 서브넷의 방화벽

• 역할: 서브넷 수준의 트래픽을 필터링하는 1차 방어선입니다.
• 상세 설명: 패킷이 my-public-subnet-a에 들어가기 직전, 서브넷에 연결된 NACL의 인바운드 규칙을 검사받습니다. NACL 규칙은 번호가 낮은 순서대로 평가되며, 허용(Allow) 또는 거부(Deny) 규칙을 따릅니다. 예를 들어, "모든 IP(0.0.0.0/0)에서 오는 HTTP(포트 80) 트래픽을 허용하라"는 규칙이 있다면, 패킷은 이 검사를 통과합니다. 만약 일치하는 허용 규칙이 없다면 패킷은 여기서 차단됩니다.

Step 6: 보안 그룹 (Security Group) - 인스턴스의 개인 경호원

• 역할: 인스턴스 수준의 트래픽을 필터링하는 2차 방어선입니다.
• 상세 설명: NACL을 통과한 패킷은 마침내 웹 서버 EC2 인스턴스의 네트워크 인터페이스(ENI)에 도달합니다. 하지만 아직 애플리케이션에 전달되지 않습니다. 마지막으로 인스턴스에 연결된 Web-SG 보안 그룹의 인바운드 규칙을 검사받습니다. 보안 그룹은 상태 저장(Stateful) 방식이며, 허용(Allow) 규칙만 가집니다. "모든 IP(0.0.0.0/0)에서 오는 HTTP(포트 80) 트래픽을 허용하라"는 규칙이 있다면, 패킷은 최종적으로 이 관문을 통과합니다.

Step 7: EC2 인스턴스 도착

• 역할: 요청을 처리하고 응답을 생성합니다.
• 상세 설명: 모든 네트워크 및 보안 검사를 통과한 패킷은 드디어 EC2 인스턴스의 운영체제(OS)에 전달되고, 웹 서버 애플리케이션(예: Nginx, Apache)이 이 요청을 받아 처리한 후 응답을 생성합니다. 이 응답 패킷은 다시 역순의 과정을 거쳐 사용자에게 전달됩니다.

Outbound Traffic 심층 분석: Private Subnet의 인터넷 연결 여정

시나리오 1: NAT Gateway가 없을 때 (연결 실패)

Private Subnet의 EC2 인스턴스가 NAT Gateway 없이 인터넷 통신을 시도하면 어떻게 될까요?

Step 1: 요청 발생

• 역할: 외부 인터넷으로 향하는 트래픽을 생성합니다.
• 상세 설명: my-private-instance(10.0.11.100)에서 yum update 명령을 실행합니다. 이로 인해 외부 업데이트 서버(52.94.236.48)로 향하는 데이터 패킷이 생성됩니다.

Step 2: 인스턴스 및 서브넷 보안 통과

• 역할: 아웃바운드 보안 규칙을 검사합니다.
• 상세 설명: 패킷은 먼저 인스턴스에 연결된 App-SG의 아웃바운드 규칙을 통과합니다 (기본적으로 모두 허용). 그 다음, my-private-subnet-a에 연결된 NACL의 아웃바운드 규칙을 통과합니다 (기본적으로 모두 허용).

Step 3: 라우팅 테이블 조회 및 경로 탐색 실패

• 역할: 패킷의 다음 목적지를 결정합니다.
• 상세 설명: 패킷은 VPC의 암시적 라우터로 전달됩니다. 라우터는 이 패킷의 출처가 my-private-subnet-a이므로, 이 서브넷에 연결된 my-private-rt-a 라우팅 테이블을 참조합니다.
  • 목적지: 52.94.236.48
  • 규칙 확인: 라우터는 my-private-rt-a의 규칙 목록을 확인합니다. NAT Gateway가 없으므로, 이 테이블에는 VPC 내부 통신을 위한 10.0.0.0/16 -> local 경로만 존재합니다.
  • 경로 부재: 목적지 IP 52.94.236.48은 local 경로에 해당하지 않으며, 그 외에 일치하는 다른 경로(예: 0.0.0.0/0)가 없습니다.

Step 4: 패킷 폐기 (Packet Drop)

• 역할: 갈 곳 없는 패킷을 처리합니다.
• 상세 설명: 암시적 라우터는 이 패킷을 어디로 보내야 할지에 대한 지침을 찾지 못했으므로, 패킷을 폐기합니다. 결과적으로 my-private-instance는 외부 서버로부터 아무런 응답을 받지 못하고, 연결은 시간 초과(timeout) 오류와 함께 실패합니다.

시나리오 2: NAT Gateway가 있을 때 (연결 성공)

이제 동일한 요청이 NAT Gateway를 통해 어떻게 성공적으로 처리되는지 단계별로 분석해 보겠습니다.

Step 1 & 2: 요청 발생 및 초기 보안 통과

• 상세 설명: 시나리오 1과 동일하게, my-private-instance에서 생성된 패킷이 App-SG와 NACL의 아웃바운드 규칙을 정상적으로 통과합니다.

Step 3: Private 라우팅 테이블을 통한 경로 지정

• 역할: 패킷을 NAT Gateway로 전달합니다.
• 상세 설명: 패킷은 VPC의 암시적 라우터로 전달되고, 라우터는 my-private-rt-a 라우팅 테이블을 참조합니다.
  • 목적지: 52.94.236.48
  • 규칙 확인: 라우터는 "가장 구체적인 경로 우선" 원칙에 따라 규칙을 확인합니다. 52.94.236.48은 10.0.0.0/16(local)에 해당하지 않지만, 0.0.0.0/0 경로에는 해당합니다.
  • 경로 선택: 라우터는 0.0.0.0/0 -> nat-xxxxxxxx 규칙을 선택하고, 패킷을 my-nat-gw-a로 전송합니다.

Step 4: Public Subnet NACL 인바운드 검사

• 역할: NAT Gateway가 위치한 Public Subnet으로 진입하는 트래픽을 검사합니다.
• 상세 설명: 패킷이 my-public-subnet-a로 진입하면서 해당 서브넷의 NACL 인바운드 규칙을 검사받습니다. 일반적으로 VPC 내부 트래픽(10.0.0.0/16)을 허용하는 규칙이 있어 통과합니다.

Step 5: NAT Gateway에서의 주소 및 포트 변환 (SNAT/PAT)

• 역할: 패킷의 출발지 주소와 포트를 변경하고 상태를 추적합니다.

• 상세 설명:
  - 변환 전: Source: 10.0.11.100:45678 → Destination: 52.94.236.48:443
  - 변환 후: Source: 203.0.113.12:23456 → Destination: 52.94.236.48:443
  - Connection Tracking: NAT Gateway는 5-tuple 정보를 상태 테이블에 저장:

    Original: (10.0.11.100, 45678, 52.94.236.48, 443, TCP)
    Translated: (203.0.113.12, 23456, 52.94.236.48, 443, TCP)

Step 6: NAT Gateway에서 IGW로 직접 라우팅

• 역할: NAT Gateway가 AWS 관리형 서비스로서 IGW로 직접 전송합니다.
• 상세 설명:
  - NAT Gateway는 별도의 라우팅 테이블 조회 없이 자동으로 IGW 경로를 인식합니다.
  - AWS 관리형 서비스의 내부 최적화로 직접 IGW와 통신합니다.
  - Public Subnet NACL의 아웃바운드 규칙 검사를 받습니다.

Step 7: Internet Gateway 처리

• 역할: VPC와 인터넷 간 연결을 중개합니다.
• 상세 설명:
  - IGW는 이미 공인 IP(203.0.113.12)를 가진 패킷이므로 추가 NAT 없이 인터넷으로 전송합니다.
  - IGW는 NAT Gateway의 Elastic IP를 인식하고 있으며, 응답 트래픽을 올바르게 라우팅합니다.

Step 8: 인터넷 통신

• 역할: 외부 서버와 통신합니다.
• 상세 설명: 외부 서버(52.94.236.48)는 요청을 NAT Gateway의 공인 IP(203.0.113.12:23456)로부터 받습니다.
  서버는 Private 인스턴스의 실제 IP를 알 수 없습니다.