퍼블릭 서브넷과 프라이빗 서브넷 만들기

0. 개요

 

VPC에 대한 개념을 쉽게(+잘) 설명해주신 글이라 공유하도록 하겠습니다! 읽어보신 후 진행하시면 좋을 것 같습니다 :)

 

[AWS] 가장쉽게 VPC 개념잡기

 

1. VPC 생성하기

 

 

먼저 VPC를 생성하도록 하겠습니다. AWS 콘솔에 로그인 후, VPC 대시보드로 이동해줍니다. 그 후 VPC 생성버튼을 누르면 위와 같은 창이 뜨게 되는데 이름은 선택적으로 정해주시면 됩니다. IPv4 CIDR블록은 특별한 이유가 없다면 10.0.0.0/16 범위에서 설정해주시면 됩니다. 10.0.0.0/16 으로 설정 시, 10.0.0.0 ~ 10.10.255.255까지 사용 가능합니다. 그 후 나머지 옵션은 기본값으로 둔 뒤 생성해줍니다. VPC 생성 후 라우팅 테이블만 자동적으로 만들어지는 것을 확인하실 수 있습니다.

 

 

2. 서브넷 만들기

 

이번에는 private, public 인스턴스를 담을 서브넷을 각각 생성하도록 하겠습니다. 서브넷 생성 버튼을 누르면 다음과 같은 창이 뜨는데, 아까 만들어 주었던 VPC를 선택하여 줍니다. 서브넷은 VPC에 포함되어야 하며, 그 VPC 범위 내에서만 IPv4 CIDR를 설정할 수 있습니다. 또한 서브넷 끼리 범위가 겹쳐서는 안됩니다!

 

public 인스턴스를 위한 서브넷은 10.10.1.0/24로, private 인스턴스를 위한 서브넷은 10.10.1.0/24로 설정하겠습니다.

 

<public subnet>

가용 영역 (AZ) : 2a

IPv4 CIDR 블록 : 10.0.0.0/24

 

 

<private subnet>

가용 영역 (AZ) : 2c

IPv4 CIDR 블록 : 10.0.1.0/24

 

 

3. 인터넷 게이트웨이 생성

 

이번에는 인터넷 게이트웨이를 생성하겠습니다. 단순히 이름을 설정해주시고 생성버튼만 누르면 됩니다. 저는 이름-igw으로 설정해주었습니다.

 

 

생성 후 '상태'가 Detached와 Attached가 있는 것을 볼 수 있는데, Detached는 어떠한 VPC와도 연결되지 않은 상태를 말합니다. 

 

 

그렇다면 생성한 인터넷 게이트웨이를 VPC에 연결하겠습니다. 이것도 매우 간단합니다. [작업]-[VPC에 연결]을 눌러 주신 후에

 

 

VPC 선택부분에서 아까 만들었던 VPC를 선택후 인터넷 게이트웨이 연결 버튼을 눌러주시면 됩니다.

 

 

 

4.  라우팅 테이블 생성

 

 

방금 전까지 인터넷 게이트웨이를 생성하여 인터넷 게이트웨이와 VPC는 연결해주었지만, 각각의 서브넷과는 연결이 되지 않은 상태입니다. VPC와 서브넷은 반드시 라우팅 테이블과 연결되어 있어야하므로, 퍼블릭 인스턴스와 프라이빗 인스턴스에 연결할 라우팅테이블을 각각 만들도록 하겠습니다.

 

 

VPC를 만들면 자동적으로 라우팅 테이블을 생성해주는데, 해당 VPC의 라우팅 테이블을 살펴보겠습니다.

 

 

각 서브넷들은 어떤 라우팅 테이블과 명시적으로 연결되어 있지 않기 때문에 기본 라우팅 테이블에 두 개의 서브넷이 동시에 연결되어있는 것을 볼 수 있습니다. 하지만 우리는 프라이빗 서브넷과 퍼블릭 서브넷을 각각 만들길 원하기 때문에 하나의 라우팅 테이블을 추가적으로 만들도록 하겠습니다. VPC생성을 통해 기본으로 만들어진 라우팅 테이블은 private인스턴스에 사용할 것인데, 라우팅 목록이 local이 기 때문입니다. (' local '은 사이드 블럭 내에 IP가 들어오게 되면 VPC 내부로 보내라는 것이므로)

 

 

퍼블릭 라우팅 테이블의 이름과 VPC를 설정한 후 라우팅 테이블을 생성해주시면 됩니다.

 

퍼블릭 라우팅 테이블이 서브넷과 연결된 상태가 아니므로, 퍼블릿 라우팅 테이블의 서브넷 연결 편집에 들어가줍니다.

 

 

퍼블릭 라우팅 테이블을 퍼블릭 서브넷과 연결해주고 저장합니다.

 

 

그렇다면 라우팅 테이블을 편집해주어야하는데, 퍼블릭 라우팅 테이블의 경우 외부 인터넷과도 연결되어야 하기 때문에 인터넷게이트웨이와 연결해주어야 합니다. 퍼블릭 라우팅 테이블을 살펴보면 현재 10.0.0.0/16 사이드블럭 내의 IP가 들어오면 같은 VPC 내로 보내라 즉 local 밖에 없는 것을 확인할 수 있습니다. 그렇기 때문에 외부 인터넷과 연결을 위해 10.0.0.0/16외의 사이드블럭 이외의 트래픽이 전달되었을 때는 인터넷 게이트 웨이로 연결해주어야 합니다. 

 

 

0.0.0.0/0 즉 모든 IP(10.0.0.0/16 외의 사이드 블럭)는 igw로 연결하고 저장합니다. 이때 0.0.0.0/0이면 모든 IP를 인터넷게이트웨이와 연결하라는거 아니야? 라는 의문이 생기게 되는데, 위에서부터 순차적으로 적용이 되므로 10.0.0.0/16외의 트래픽은 igw로 보내게 됩니다.

 

 

5. NACL 설정하기

 

AWS에서 인스턴스 보안을 설정하는 방법은 NACL을 활용하는 방법과 보안그룹을 활용하는 2가지 방법이 존재합니다. NACL은 Stateless하고, Security Group은 stateful한 특성을 가집니다. Stateful하다라는 것은 요청 정보를 저장(상태를 기억)하고 있기 때문에 응답하는 트래픽 제어를 하지 않는다는 것이며, Stateless라는 것은 요청 정보를 따로 저장하지 않기 때문에 응답하는 트래픽에 대한 필터링을 설정해야함을 의미합니다.

 

자세히 설명하자면!

 

클라이언트에서 서버로 부터 요청할 때는 해당 IP주소의 10번 포트로 요청을 하고, 서버로 부터 응답을 받을 때는 1024번 포트로 응답을 받는다고 가정해봅시다. 이 때 요청할 때의 포트번호를 Inbound라 하고 응답 받을 때의 포트번호를 OutBound라고 합니다. ( OutBound 포트는 1024 ~ 65535 중 임시로 하나를 배분해서 사용합니다.)

 

SecurityGruop은 Stateful한 특징을 가지는데 만약 클라이언트에서 EC2로 부터 요청을 하면 EC2는 SecurityGroup에 의해 오로지 80번 포트에서만 요청을 받고 응답을 보내는 OutBound가 none이지만 요청을 받았을 때의 정보를 저장하고 있기 떄문에 요청한 포트로 다시 응답을 보낼 수 있습니다. 

 

반면 NACL의 경우 Stateless한 특성을 가지기 때문에 EC2가 NACL에 의해 오로지 80번 포트에서만 요청을 받았지만 요청을 받았을 때의 State를 기억하고 있지 않기 때문에 응답을 보내지 않게 됩니다. (OutBount = none) 설명을 잘 이해하셨으면 NACL과 Security Group 중 어떤 것이 더 엄격한 보안을 가지고 있는지 아실 수 있겠죠? 

 

그렇다면 이제 NACL을 설정해보도록 하겠습니다!

 

[보안] - [네트워크 ACL] 에 들어가게되면, 우리가 만든 VPC(custom-VPC)에 대해 기본적으로 NACL이 존재하는데 이것을 private-NACL로 이름 설정을 해주겠습니다. 하지만 저희는 서브넷이 2개가 있기 때문에 public 서브넷도 NACL을 하나 더 추가해주어야 합니다. 

 

 

[네트워크 ACL 생성] 버튼을 누르면 다음과 같은 창이 뜨게 되는데, public_NACL로 이름을 설정해주시고 저희가 만든 VPC를 선택해주신 후 생성버튼을 눌러주시면 됩니다.

 

 

 

 

 

 

 

 

 

 

 

 

NACL의 경우에도 서브넷을 연결해주어야하는데 우선 퍼블릭 나클의 서브넷을 연결해주도록 하겠습니다. public_NACL의 [서브넷 연결 편집]에 들어가서 public-subnet을 선택해주시고 변경사항을 저장하면 됩니다.

 

 

위와 같이 각각 서브넷에 잘 연결된 것을 보실 수 있으실 겁니다!

 

 

아까도 말씀드렸다시피 모든 보안설정은 인바운드/아웃바운드 규칙으로 설정되어있는데 이를 설정해보도록 하겠습니다. 포트 범위를 80, 22, 433 포트를 모든 IP 주소에 대해 허용을 하고, 규칙번호를 100, 200, 300으로 설정해보록 하겠습니다.

 

 

그렇다면 인바운드 규칙이 이렇게 편집이 됩니다. 규칙 번호 대로(낮은 숫자순) 규칙이 정해지게 되는데, 만약 규칙번호 101번호 포트번호 22에 거부를 새로 만들었다고 해도 100번호에 포트번호 22 허용이 되어있으므로 포트 번호 22번은 항상 허용되게 됩니다. 하지만 포트번호 22의 규칙번호를 99로 설정하고 거부로 설정했다면 당연히 99가 먼저 적용되어서 그 요청은 거부되는 것입니다!

 

 

만약 위와 같이 규칙번호 101번에 모든 포트 범위에 대해 Deny를 설정한 인바운드 규칙으로 편집했다고 해봅시다. 80번 포트에 요청이 오면 당연히 허용이됩니다. 하지만 22번포트에 요청이 오게 되면 규칙 번호 101번으로 인해서 (규칙번호 200번에서 허용을 함에도 불구하고 101번이 먼저 적용되기때문에) 요청이 거부되게 됩니다. NACL의 경우 Stateless한 특징을 가지기 때문에 이러한 규칙을 잘 설정하는 것이 중요합니다.

 

이번에는 아웃바운드 규칙을 편집해보록 하겠습니다.

 

포트범위 사진에서 65555 를 65535라고 생각해주시면 됩니다 (오류 죄송합니다!)

 

규칙번호는 100번, 포트 1024-65535까지 허용하도록 설정하겠습니다. 아웃바운드 포트는 1024 ~ 65535 중 임시로 하나를 배분해서 사용하기 때문에 이 범위 내의 포트는 허용을 해주어야만 트래픽을 전달할 수 있게 됩니다.