본문 바로가기

Cloud Service 비교

#5 Network Part_2 Traffic Flow&Security

도입

안녕하세요. 빅두 입니다.

지난 블로그에서 Network 기본적인 기능들에 대해 비교해 보았습니다. 글을 쓰면서도 이번 블로깅으로 계속 내용을 넘겼었는데요. 넘기면 굉장히 부담이 커진다는 것도 실감해 봅니다. 앞으로는 맡은 곳에서 전부 끝내버려야겠어요.

 

이번엔 Network Traffic 흐름을 제어하는 Route, 통신을 제어하는 ACL 대해 알아보도록 하겠습니다. 사실 하나의 블로깅에서 전부 다루려고 했었습니다만.. 그렇게 되면 ~~~장한 스크롤의 압박들을 느끼실 것이고, 심지어 비교는 커녕 앞서 말한 내용이 머릿속에서 사라질까봐 일부러 내용을 나누었습니다.

 

#4 Network Part_1 Overview

#5 Network Part_2 Traffic Flow&Security

#6 Network Part_3 VPN&Peering

#7 Network Part_4 Tag&Cost&Trubleshooting

 

 

Azure

Network 단윈 까지는 Azure 먼저 이야기 해볼까 합니다. :)

Azure의 VNet 속성을 보시면 Route Table 설정할 있는 메뉴가 보이지 않습니다.

 

 

그렇다면 Route 검색해 봅시다.

검색해 보니 Route tables라는 메뉴가 있네요. 한번 들어가 볼까요~?

 

 

?????????????

관련 정보가 하나도 없습니다!? 그럼 Azure에서 Route Tables 언제 쓰는 걸까요?

아니 전에 VNet Route Table 정보는 어떻게 되어 있을까요?

답은 의외로 간단했습니다. 왜냐하면, 아래와 같이 Azure 홈페이지에 아래와 같이 설명이 되어있거든요.

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-udr-overview/

 

 

내용을 확인해 보면 VNet간의 모든 통신은 기본적으로 가능하도록 Routing 되어 있다는 입니다. 뿐만 아니라 모든 Subnet Internet으로 나가는 WAN구간 통신도 전부 가능하도록 설정되어 있습니다. 따라서 Azure에서는 기본적으로 Vnet 제작하게 되면 VNet 내부 통신은 물론, WEN 구간까지 통신이 가능하도록 기본 설정 됩니다. 설정을 System route라고 지칭합니다.

System route VNet 내의 모든 Subnet 통신과 VPN으로 연결된 네트워크간 통신, 그리고 Internet으로 전송되는 통신에 대해 설정 됩니다.

 

하지만, 사용자의 필요에 따라 특정 Subnet 한해 WEN구간 통신을 제어하고 싶거나, Subnet 통신을 변경하고 싶을 때가 있을 것입니다예를 들면 Network Virtual Appliance 장비(Cisco Nexus 1000v ) 사용할 VM들의 모든 Packet 특정 VM으로 전달이 되어야 특정 VM에서 Traffic 제어가 가능하기 때문 입니다.

 


위와 같이 Virtual Appliance 장비 또는 NAT 장비 등을 사용하실 때에는 Network Interface에서 IP Forwarding Settings Enabled 해주셔야 Packet VM 지나갈  있습니다설정이 안되어 있으면 패킷을 VM 전부 먹어버리거든요.

 

 

자세한 사항은 다음 URL 참고하시면 되겠습니다.

https://azure.microsoft.com/ko-kr/documentation/articles/virtual-networks-udr-overview/

 

Route Table 적용 우선순위는 System Route < User Route < 소규모의 CIDR Route 입니다.

 

다음으로 설명 드릴 부분은 Network Security Group (NSG)입니다.

방화벽으로 해석하시는 분들도 계시지만, 그냥 간단하게 말하면 ACL(Access Control List) 입니다. NSG 적용할 있는 리소스는 Network Interface Subnet 입니다.

 

NSG 지역 내에서 고유한 이름을 가져야 합니다. 사람이 쓰고 있는 이름으로는 만들 없는 거죠. 또한 NSG 생성된 지역 안에서만 사용이 가능합니다. Region이라는 종속성을 갖게 되네요.

 

규칙을 만드는 것은 간단합니다. Inbound Security Rules 또는 Outbound Security Rules 선택한 +Add 눌러 생성아래와 같이 생성하면 됩니다.

 

 

Source/Destination 보면 Any, CIDR block, Tag 있습니다. Any 당연히 0.0.0.0/0 가리키는 녀석이고, CIDR block CIDR값을 Fix 사용합니다. CIDR block 0.0.0.0/0 입력하게 되면 Any 다를 바가 없어 보이네요. 다음은 Tag인데요. Tag 3가지로 나누어 집니다. Internet, VirtualNetwork, AzureLoadBalancer 되어 있으며, 각각 인터넷, VNet, LB통신에 대한 정책 입니다. 프로토콜은 Any, TCP, UDP 가지만 지원하며, 80-90 같이 Range 지정할 있습니다. 개인적으로 아쉬운 것은 ICMP 별도로 지정할 없다는 점이 매우매우 아쉽네요.

기존 ACL 동일하게 우선순위를 지정할 있으며 수치는 100~4096까지 지정할 있습니다. 물론 정책의 제일 마지막에는 해당 정책을 허용할 것인지, 거부할 것인지에 대한 Allow, Deny 선택할 있습니다.

 

모든 NSG에는 Default Rule 존재하며, 정책은 다음과 같습니다.


Inbound

Priority

Source

S_Port

Destination

D_Port

Protocol

Access

65000

VIRTUAL_NETWORK

*

VIRTUAL_NETWORK

*

*

Allow

65001

AZURE_LOADBALANCER

*

*

*

*

Allow

65500

*

*

*

*

*

Deny

 

Outbound

Priority

Source

S_Port

Destination

D_Port

Protocol

Access

65000

VIRTUAL_NETWORK

*

VIRTUAL_NETWORK

*

*

Allow

65001

*

*

Internet

*

*

Allow

65500

*

*

*

*

*

Deny

 

위에서 언급했습니다만, NSG Network Interface Subnet 연결할 있습니다.

NSG 여러 개의 Network Interface Subnet 연결할 있습니다만, 하나의 Network Interface 또는 Subnet 여러 개의 NSG 연결할 없습니다. , NSG 적용 받는 Resource 하나의 NSG만을 연결할 있습니다. Subnet 적용하는 NSG 경우, 해당 Subnet 해당하는 모든 Resource들이 영향을 받기 때문에 적용 주의해야 합니다. 내용은 다음 URL에서 자세히 확인하실 있습니다.

https://azure.microsoft.com/ko-kr/documentation/articles/virtual-networks-nsg/#-4

 

NSG 정책이 적용되는 순서는 다음과 같습니다.

 

 

풀어서 설명을 드리자면, Inbound Traffic Subnet NSG 거쳐 Network Interface NSG 순으로 정책 적용을 받으며, Outbound Inbound와는 반대로 Network Interface NSG 거쳐 Subnet NSG 순으로 정책 적용을 받습니다.

 

제한 사항으로는 구독당 NSG 100개까지 생성이 가능하며 NSG Rule 200개를 넘지 못합니다. 각각 리소스는 티켓을 열어 제한 증가가 가능하며, 구독당 NSG 200, NSG Rule 400 까지 증설이 가능합니다.

자세한 내용은 아래 URL 참고하시기 바랍니다.

https://azure.microsoft.com/ko-kr/documentation/articles/azure-subscription-service-limits/#networking-limits

 

NSG 구성할 가지 주의사항이 있습니다.

  1. VPN Gateway 또는 Express 경로에 대한 Subnet에는 NSG 적용하면 안됩니다. 적용 Cross VNet 또는 Cross Premise 연결이 동작하지 않을 있습니다.

  2. 부하 분산 장치에 대한 정책은 Default Rule 지정이 되어있기 때문에 굳이 수정할 필요는 없습니다.

  3. Host Node Virtual IP 대해 제한을 하면 안됩니다. IP 모든 Host 동일하게 168.63.129.16으로 사용하고 있으며, 통신에 제한이 생길 경우 DHCP 릴레이, DNS 재귀 확인자, 부하 분산 장치의 Healthy Check, VM Healthy Check 등이 동작하지 않을 있습니다.

  4. VM Windows Server라면, KMS(라이선싱) 통신에 대해 제한을 하면 라이선스에 문제가 발생할 있습니다. Outbound 1688 대해서는 제한을 두지 말아야 합니다.

 

여기까지 Azure NSG 대해 알아보았습니다. 만약 NSG 대해서 구성을 하고자 하시는 분들은 Azure Guide에서 제공하는 샘플을 먼저 확인하신 NSG 디자인을 하시는 것을 추천 드립니다.

https://azure.microsoft.com/ko-kr/documentation/articles/virtual-networks-nsg/#-10

 

 

AWS

이번엔 AWS 네트워크에 대해 살펴보도록 하겠습니다.

우선 AWS VPC 생성하면 기본적으로 Route Tables 생성이 됩니다.

 

 

Route Table Name Tag 달고 실제 Routes 탭으로 이동해 보면 보시는 바와 같이 VPC CIDR값에 대해 Local이라는 정책이 설정되어 있습니다. 이는 기본 정책이며, 수정 삭제가 되지 않습니다. 무조건 VPC 내부통신에 대해서는 Routing 수정을 없다는 의미죠.

Route Table Main속성 값이 있는데요. 이것은 VPC 생성된 Subnet Route Table 설정하지 않으면 자동으로 해당 Route Table 적용 받겠다는 의미입니다. 그럼 Subnet 제작하면 기본적으로 Main 속성이 Yes Route Table 정책을 적용 받겠죠?

 

AWS Route Table VPC 종속을 받습니다. Azure VNet 종속을 받지 않습니다만, 사실 Route Table같은 경우는 종속을 받는다고 해서 크게 문제가 없어 보입니다. 오히려 종속을 받는 것이 낫지 않을까? 라는 생각도 봅니다.

 

그렇다면 AWS에서 인터넷(WAN 구간)통신을 하려면 어떻게 해야 할까요?

AWS에는 Internet Gateway(IGW)라는 녀석을 VPC 연결시켜서 Route Table 설정해 주어야 합니다.

 

IGW 그대로 Gateway이며 VPC Attach하는 방식입니다.

 

 

IGW VPC Attach 하게 되면 Route Table에서 Target으로 설정할 있게 되며, IGW 설정하고 나면 다음과 같이 설정을 있습니다.

 

 

Azure 다르게 Destination CIDR값만 설정이 가능하며, IGW를 Target 으로 여러 개의 Route Table 만들 없기 때문에 Internet 하려면 0.0.0.0/0 대해 IGW Routing 되도록 설정해야 합니다.

AWS에서는 기본적으로 IGW 또는 NAT 설정되어 외부와 통신이 가능한 Route Table 가진 Subnet Public Subnet이라고 지칭하며, 그렇지 않은 Subnet Private Subnet이라고 지칭합니다.

 

AWS에서도 Azure 같이 Virtual Appliance 장비 또는 NAT 장비 등을 사용하실 때에는 EC2(VM)에서 Cheange Source/Dest. Check 메뉴로 들어가 설정을 Disable 주셔야 합니다. 설정이 안되어 있으면 패킷을 VM 전부 먹어버리거든요. 그리고 해당 설정을 하지 않게 되면 Route Table에서 Target으로 EC2 설정할 없습니다.

 

 

한가지 아쉬운 점은 위에서 언급 드린대로 기본 Route Table Local 설정은 변경이 불가능합니다. 따라서 Virtual Appliance 장비를 쓰실 VPC 내부 트래픽에 대해서는 AWS에서 제공하는 데이터로만 제어가 가능하다는 입니다.

매우 안타까운 점입니다만, 어쩔 없습니다. 지원을 안 하는걸요….

 

AWS에서는 보안사항으로 Network ACL Security Group 제공합니다. Azure에서는 NSG라는 리소스로 한번에 지원하는 반면, AWS에서는 Subnet 대한 ACL Network ACL(NACL) 별도 제공합니다.

 

 

 

기본적으로 NACL에서는 위에서 보시듯 어느 것도 제어하지 않습니다. 따라서 ACL 설정을 원하시면 직접 수정을 하시면 되며, 설정은 TCP, UDP, ICMP, ALL Traffic 제공합니다. 또한 NACL에서는 CIDR값을 기준으로만 설정이 가능합니다.

 

다음은 Security Group입니다.

AWS Security Group NACL 같이 TCP, UDP, ICMP, ALL Traffic 지원합니다. 하지만 ACL 특징인 Allow, Deny정책을 적용시킬 없으며, Rule 정의하는 순간 해당 Rule Allow 적용이 됩니다. Security Group Azure 마찬가지로 ENI 적용이 가능합니다.

 

 

 

기본적으로 Security Group 만들면 Inbound Rule 없고 Outbound Rule ALL 열려있습니다. Edit 눌러 정책을 수정한 Save 누르면 바로 정책이 적용됩니다.

Source/Destination에는 여러가지 내용을 입력할 있습니다. 기본적으로 CIDR값의 입력은 물론, Security Group ID 입력하여 Security Group 적용된 Instance 통신을 제어할 수도 있습니다.

 

 

이는 Security Group간의 정보로 공유하는 것으로 Subnet 다른 여러 EC2들에 대한 정책을 설정할 매우 유용하게 사용됩니다. 오히려 CIDR 아닌 Security Group ID만으로 통신 설정을 함으로써 다음과 같이 Service 기준으로 적용할 Security Group 정의하고 적용할 있는 시나리오가 가능하게 됩니다.

 

 

AWS Security Group은 하나의 ENI에 여러 개의 Security Group 설정할 있으며, 정책 적용은 ENI 연결된 모든 Rules 합친 결과가 나오게 됩니다.

 

 

이런 방식으로 Security Group Resource 적용할 있어 Security Group 조합이라는 개념으로 Rules 설정할 있습니다.

 

정책이 적용되는 순서는 Azure 같이 Inbound 경우 VPC 외부 -> NACL -> Security Group -> Instance 이며, Outbound 경우 Instance -> Security Group -> NACL -> VPC 외부 입니다.


AWS Security Group의 임계값은 다음과 같습니다.

기본 VPC당 Security Group 개수의 한계는 500개이며, AWS Case를 통해 증가시킬 수 있습니다. 하나의 Security Group에서 정의할 수 있는 Rules 개수는 50개(Inbound+Outbound)이며, 하나의 ENI에서 연결할 수 있는 Security Group의 개수는 5개 입니다. 이것들도 마찬가지로 AWS Case로 증설, 축소가 가능하지만, 하나의 Security Group에서 정의할 수 있는 Rules 개수와 하나의 ENI에서 연결할 수 있는 Security Goup 개수의 곱은 250을 넘을 수 없습니다. 즉, 하나의 ENI에 적용될 수 있는 Security Group Rules 개수는 총 250개를 넘지 못한다는 것을 의미 합니다. 이는 Azure에 비해 약 150개 적은 수치입니다.

 

 

맺음말

Network 흐름과 제어에 대해서 알아보았습니다.

일단 Routing에서 Azure Open based, AWS Close based 전혀 반대의 양상을 보실 있습니다. AWS 일단 막고보자는 것인 같고, Azure 사용자 편의를 위해 중간단계를 같은 느낌이 듭니다. 아니면 다른 이유일 수도 있을 같고요.

 

어찌됐든, 그로 인해서 발생하는 부분은 외부통신을 제어하고 싶은데 제어를 위해서는 무언가 작업을 주어야 한다는 것이 Azure, 외부와 통신을 하기 위해서는 무언가 작업을 주어야 한다는 것이 AWS 생각하면 매우 심플할 같습니다.

 

개인적으로는 후자 모델이 마음에 드네요. 여러분들 생각은 어떠신가요?

 

같은 Subnet 지라도 Traffic 다른 Routing 설정할 있는 Azure 장점과, Security Group 대상으로 Rules 설정하고, 중복 적용할 있는 AWS 장점이 전달 됐을지 모르겠습니다.

 

다음엔 #6 Network Part_3 VPN&Peering 이라는 제목으로 블로깅 하도록 하겠습니다. 혹시 이번 편에서 문제가 있거나, 잘못된 내용이거나, 추가가 되었으면 하는 내용이 있다면, 페이스북을 통하거나 댓글을 달아주시면 감사하겠습니다.

 

읽어 주셔서 감사합니다.

 

#4 Network Part_1 Overview

#5 Network Part_2 Traffic Flow&Security

#6 Network Part_3 VPN&Peering

#7 Network Part_4 Tag&Cost&Trubleshooting

 

참고자료 :

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-overview/

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html/


==============================

수정 1: AWS의 Security Goup에 대한 Limit 작성

'Cloud Service 비교' 카테고리의 다른 글

#4 Network Part_1 Overview  (0) 2016.07.07
#3 Resource를 관리하는 자  (0) 2016.05.26
#2 VM(가상컴퓨터)에 대하여  (1) 2016.05.25
#1 고 가용성의 기준 Region  (2) 2016.04.21
IT Pro를 위한 IT Pro Cloud Essential  (0) 2016.04.21