도입
안녕하세요. 빅두 입니다.
지난 블로그에서 Network의 기본적인 기능들에 대해 비교해 보았습니다. 글을 쓰면서도 이번 블로깅으로 계속 내용을 넘겼었는데요. 넘기면 굉장히 부담이 커진다는 것도 실감해 봅니다. 앞으로는 맡은 곳에서 전부 끝내버려야겠어요.
이번엔 Network의 Traffic 흐름을 제어하는 Route와, 통신을 제어하는 ACL에 대해 알아보도록 하겠습니다. 사실 하나의 블로깅에서 전부 다 다루려고 했었습니다만.. 그렇게 되면 굉~~~장한 스크롤의 압박들을 느끼실 것이고, 심지어 비교는 커녕 앞서 말한 내용이 머릿속에서 사라질까봐 일부러 내용을 나누었습니다.
#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을 참고하시기 바랍니다.
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 이라는 제목으로 블로깅 하도록 하겠습니다. 혹시 이번 편에서 문제가 있거나, 잘못된 내용이거나, 추가가 되었으면 하는 내용이 있다면, 페이스북을 통하거나 댓글을 달아주시면 감사하겠습니다.
긴 글 읽어 주셔서 감사합니다.
#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 |