안녕하세요 오늘은 네이버 클라우드 플랫폼 이죠 NCP 에 대해서 적어 보려고 합니다.

최근 1년사이에 www.ncloud.com/ 에서도

네이버 클라우드 플랫폼의 최근 추가된 VPC 

VPC(Virtual Private Cloud) 가 출시 되며 기존에 있던 네이버 클라우드 플랫폼에 Classic 환경에서 사용하던

ACG(AccessControlGroup) 은 VM < - > VM 단위의 네트워크 룰을 적용하였다면 VPC가 출시되면서 Subnet 이라는 개념과 함께 Subnet < - > Subnet 의 네트워크 룰을 적용할수 있는 NACL 이 등장하게 되었습니다.

기본적으로  NACL 은 ACG와는 조금 다른 형태를 띄고 있기 때문에 이에 대해서 간단하게 적어 놓도록 하겠습니다.

 

NACL ( Network  Access Control List ) 

네이버 클라우드 플랫폼 환경에서 기존에 Classic에 경우는 ACG를 통하여서 VM 간의 차단룰을 적용했다면 NACL의 경우에는 Subnet 을 통한 차단룰을 적용합니다.  간단하게 설명된 곳이 있어 첨부합니다.

출처 : 코스콤 금융 클라우드 www.koscom.cloud/product/networking/vpc

서버의 접근 제어 서브넷의 접근 제어
허용 (Allow) 허용 및 거부 (Allow/Deny)
상태 저장
(규칙에 관계없이 반환 트래픽이 자동으로 허용됨)
상태 비저장
(반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함)
ACG를 서버의 NIC에 적용 서브넷에 있는 모든 서버에 자동 적용됨

흔히 ACG는 Stateful NACL 은 Stateless라고 표현을 하기도 합니다.  ACG는 따로 포스 중이기 때문에 거기서 설명하도록 하겠습니다. 

NACL 을 적용해 보기 위해서는 일단 네이버클라우드플랫폼에서 VPC와 Subnet을 하나 만들어야합니다.

VPC 생성

Console 접속 후 VPC - VPC Management 에서 [ + VPC 생성 ] 을 클릭하여 아래와 같이 생성합니다.

기본적으로 특수 목적용 사설 IP대역은 위의 범위내에서 지정하도록 되어있기 때문에 저는 10.2.0.0/16 대역으로 지정하였습니다. 이부분에 대해서도 CIDR에 대한 설명이 필요하지만 해당 포스팅에선 따로 설명하지 않겠습니다.

생성이 완료되면 VPC내부에 VM 을 놓기 위한 Subnet을 생성합니다.

 

Subnet 생성 

VPC Management 바로 밑에 있는 Subnet Management 로 들어가서 [ + Subnet 생성 ] 을 선택합니다.

원하는 서브넷 이름을 정하고 방금 생성한 VPC를 선택하도록 합니다.

 

VM 생성

VM 생성은 이제 일반적인 서버 생성을 하신다고 보면되며 2개의 VM 이 생성되었다고 가정하겠습니다.

Send-Server( 10.2.1.55 )    

Recv-Server ( 10.2.1.77 )

 

NACL

NACL 은 기본적으로 VPC가 생성됨에 따라서 vpc-default-network-acl 이 하나 생성되며 아무런 룰도 존재하지않습니다.

NACL 의 Default 룰은 ALLOW 입니다. 그렇기 때문에 기본적인 서버를 생성시에는 ACG룰에 의하여 적용이 됩니다. (ACG는 Default DENY)

위와같이 NACL 의 경우 Default 가 "ALLOW" 이기 때문에 아무런 룰이 없어도 NACL 규칙에 위반되는 트래픽이 발생하지않습니다. 

 

해당 상황에서 

Send-Server( 10.2.1.55 )  ==== > Recv-Server ( 10.2.1.77 ) 에서 10.2.1.77 의 22번 포트차단시 단순하게는 

Case 1

   InBound 10.2.1.77  22 차단

Case 2

   OutBound 10.2.1.77 22 차단

 

2개의 케이스를 도출해낼수 있다고 생각 할수 있는데요  실제로 케이스 1번은 차단되지않습니다. 

처음에 잘못 생각 했던 부분이 Case 1번과 같이 룰을 지정해 놓게 되면

Send-Server 에서 -> Recv-Server 까지는 트래픽이 나가고 ( 인바운드만 차단이니까 ) 다시 들어올 때 10.2.1.77 의 22번 포트로 들어오겠지? 라는 생각에 당연히 막히겠지 라는 잘못된 생각을 가질수 있습니다.

 

간단하게 정리하면

 

NACL

-- inbound 포트 : 목적지 포트 ( VM 으로 들어오는 port )

-- outbound 포트 : 출발지 포트 ( VM 에서 나가는 port )

 

그럼 1번 케이스가 차단이 되어야 하지 않나? 라고 여기서고 생각한다면 OS에 특징을 봐야합니다. 네이버클라우드플랫폼에 있는 Centos 7.8 OS를 기준으로 하게되면  inbound 룰을 차단하게 되면  10.2.1.77 로는 일단 트래픽이 나가고 

다시 들어오는 IP 와 포트의 22을 차단하게 됩니다. 실제로 들어오는 IP는 10.2.1.77 이 들어옵니다. 하지만 Port는 랜덤하게 지정해줘서 들어오게 됩니다.  해당 포트 는 1024 ~ 65535 에서 랜덤으로 주게 되었으며 실제로 우리가 알고 있는 port의 범위는

 

0 ~ 1023 : well-known port번호 해당 영역의 port번호는 UNIX/LINUX에서 root 권한으로만 port를 열 수 있습니다. 예약영역이라고 보면 됩니다. 

1024 ~ 49151번: 등록된 포트 (registered port) 이 영역은 주로 서버 소켓으로 사용하는 영역입니다. 

49152 ~ 65535번 : 동적 포트(dynamic port) 이 영역은 client가 connect(2)시 또는 bind(2)없이 server socket을 생성했어 listen(2)할 경우에 자동으로 할당되는 영역입니다. server socket에서 자동할당하면, client에게 할당된 port번호를 알릴방법이 있어야하기 때문에 서버 소켓은 prot번호를 정합니다.

위와같은 영역이 정해져있습니다. 하지만 우리가 쓰고있는 VM들은 어느 범위 내에서 포트를 할당할시 알수가 있습니다.

바로 port_range 인데요 

네이버 클라우드 플랫폼의 VM인 Centos 7.8 을 기준으로 

vi /proc/sys/net/ipv4/ip_local_port_range

결과

32768   60999

 

해당 범위내에서 포트를 지정해서 다시 돌려주도록 되어있습니다. 제가 Express.js나 Java 서버든 장고를 사용하든 해당 OS설정으로 인해서 해당 포트의 범위를 돌려줍니다.

 

그래서 위의 상황에서 CASE는 아래와같이 변경되어야 합니다.

 

Send-Server( 10.2.1.55 )  ==== > Recv-Server ( 10.2.1.77 ) 에서 10.2.1.77 의 22번 포트 차단시 단순하게는

Case 1

   InBound 10.2.1.77  32768-60999 차단

Case 2

   OutBound 10.2.1.77 22 차단

 

이렇게 되면 1번 케이스에서 55서버는 77서버로 아웃바운드 트래픽을 정상적으로 나가고 77서버는 55서버에게 다시 돌려주기 위해서 10.2.1.77:(32768-60999) 포트를 돌려주게 되며 해당 룰은 차단되어있기 때문에 10.2.1.55 서버에서 NACL 에 의해 막히게 됩니다. 

 

간단하게 NACL 에 대해 살펴 보았습니다. 사실 위에 부분 말고는 처음 NACL 을 접하였을 때 특이사항은 없었던 것 같습니다.  잠깐 신경 안쓰다 보니 다시 잊혀져 가는거 같아서 포스팅을 해놓았습니다.  ㅎㅎ

 

 

감사합니다.

+ Recent posts