AWS VPC & 서브넷

AWS의 VPC로 자신만의 Virtual 네트워크를 형성 할 수 있다.  이를 위해선 사실 많은 사전 지식을 필요한다. 특히 네트워크의 기본을 알고 있어야 한다. 하지만 자유자재로 확장할수 있는 클라우드상의 VPC를 가지는 것은 매우 매력적이다. 

잠시 여기서 초보자가 VPN과 VPC가 이가 헷갈린다면 https://mycodelife.tistory.com/18 먼저 블로그를 읽어보고 개념을 확실히 잡는것을 추천한다.

 

간략히 기능들을 설명하자면 

• Subnet이란 VPC에 있는 IP 주소의 Range를 말한다. Subnet은 반드시 single AZ에 있어야 한다. 
• IP addresss로 EC2, NAT gateways 그리고 Network Loadbalancer등을 할당한다. 
• Routing은 VPC를 생성하면서 Main Route table을 자동으로 생성한다.  이 main route table이 모든 subnets을 관장한다. 
  • Destination이란 이는 IP 주소의 모음으로 어디로 트래픽을 보낼지 결정한다. 
  • Target이란 Gateway, network interface 또는 destination서 할당한 connenction 즉, internet connection을 이야기 한다. 
  • Route table association이란 Route Table 과 subnet internet gateway 도는 virtual private gateway등과 연계한다. 
  • 또한 local/subnet route에 따라 연결하는 connenction에 따라 이름이 나뉘어 진다. 
  • Route Propagation이란 virtual private gate가 자동으로 해당 route table들에 Route할수 있도록 해준다. 그럼으로 이를 활용하면 수동으로 VPN의 Route를 설정할 필요가 없는것이다.  더 자세한 정보는 https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html 여기서 읽을수 있다. 미안하지만 영어밖에 없다...
  • SITE to SITE VPN Routing option은 사이트구조를 Microservie로 다양한 사이트를 형성하여 트래픽을 줄일때 매우 활용도가 높다. 
  • Gateway route table은 internet gateway나 virtual private gateway와 관련이 있다.
  • Edge Association은 Inbound 되는 VPC 트래픽을 appliance 장치(?)에 route해 줄때 활용이 가능하다. 
  • Transit Gateway Route table은 별도로 https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html 에서 상세히 설명하고 있다.  
  • Local gateway route table은 Outpost local gateway를 말한다. 이것도 별도로https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html에서 설명해주고 있다. 참고 할수 있다.
• 서브넷 라우트 테이블 
  • VPC는 절대적 Router 이다. 반드시 VPC는 반드시 subnet 연결되어 있어야한다. 이는 서브넷 테이블을 통해 콘트롤하기 위해서이다. 하지만 위에 설명한 데로 Main Route Table을 통해 이하 라우트를 콘트롤 할수 있다. 서브넷을 하나의 라우트 테이블로만 연결이 된다. 
  • 각 라우트는 라우트 테이블에서 Destination과 target을 정의한다. 이는 인터넷 게이트웨이를 접속할수 있도록 하고 해당되는 라우트를 서브넷 라우트 테이블에 추가한다. Route의 Destination은 0.0.0.0/0로 IPv4주소를 나타낸다. 
  • Target은 VPC에 연결된 internet gateway를 말한다

 

CIDR은 블록은 IPv4와 IPv6는 서로 별도로 취급되어진다. 예를들어 0.0.0.0/0의 CIDR의  destination은 자동으로 IPv6를 포함하지 않는다. 

반드시 CIDR ::/0을 가진 destination을 모든 IPv6에 설정해 주어야 한다. 만약 같은 CIDR set을 가진 블록을 참고해야 한다면 customer-managed prefix list를 생성하고 관리해야 한다. 모든 라우트 테이블은 VPC내에 로컬 커뮤니케이션이 가능하도록 로컬 라우트를 포함 한다. 그럼으로 생성한 테이블은 각 IPv4 CIDR블록을 가지고 있는것이다. 

 

예시) Customer-Managed에서 우선순위 7.7.7.7 의 주소로 Packet을 보낸다고 가정할 경우
1. 7.7.7.7  과 255.255.255.0에 대해 AND 연산 진행 후 Destination 192.168.0.0 값과 비교한다. 
두 값은 일치하지 않으므로 유효하지 않다.
2. 7.7.7.7  과 255.0.0.0에 대해 AND 연산 진행 후 Destination 111.0.0.0 값과 비교합니다. 
두 값은 일치하지 않으므로 유효하지 않습니다.
3. 7.7.7.7 과 0.0.0.0에 대해 AND 연산 진행 후 Destination 0.0.0.0 값과 비교합니다. 
두 값은 정확하게 일치하므로 해당 인터페이스로 192.168.0.1의 게이트웨이를 통해 Packet을 송수신합니다.

추가로 게이트웨이에서 0.0.0.0 값을 가지는 것은 해당 줄은 로컬로 연결되어 있어 외부 네트워크로 나갈 게이트웨이가 없다는 표현입니다.
0.0.0.0 은 "미지정"이라는 특정 의미를 갖고, 이는 게이트웨이의 맥락에서 "없음"으로 표현할 수 있습니다.
결론적으로 네트워크가 해당 인터페이스에 로컬로 연결되어 있음을 알 수 있습니다.

 

• 규칙과 고려사항
  • Route를 Route Table에 추가할때 Destination은 반드시 전체 IPv4에 맞추어야 하고 Target은 NAT gateway나 Network Interface 또는 Gateway Load Balancer의 endpoint에 맞춰야 한다. 
  • Route table에 Multiple Route가 존재할 경우 특정 Route에 어떻게 traffic에 맞춰야 할지를 결정하기 위해 Prefix가 가장 길게 맞는 것을 선택하게된다. 
  • IPv4 주소와 동일하거나 서브넷 Range가 169.254.169.0/22에 맞춰저 있으면 안된다. 왜냐하면 이는 Local address를 맞추기 위해 AWS에서 사용하고 있기 때문이다. 
    • 예를들어 EC2에서 사용하는 주소는 EC2 instance에서만 상요되어지기 때문이다. CIDR블록이 169.254.169.0/22.을 포함한 큰 블록으로 설정할수 있지만 패킷의 Destination이 169.254.169.0/22.으로 특정되면 포워딩이 안될것이다. 
    • 같은 이유로 IPv6가 fd00:ec2::/32. 에 매칭되서는 안된다. 
  • 예제)
    • 다음의 예제는 VPC가 IPv4 CIDR 블록을 가지고 IPv6가 CIDR블록 모두를 가지고 있을때이다. 이 테이블에서
    • IPv6는 모든 트래픽이  VPC (2001:db8:1234:1a00::/56) 로컬에 사용되어진다. 
    • IPv4과 IPv6는 위에서 언급했듯이 별도로 취급되어짐으로 모든 IPv6 트레픽은 egress-only internet gateway에만 연결이 된다. 여기서 egress-only internet gateway란 인터넷 게이트웨이를 말하며  VPC의 Instance에서 인터넷으로  IPv6를 통해 Outbound를 허용하는 콤포넌트를 이야기한다.  즉, outbound만 허용한다는 거다. 
    • 172.31.0.0/16은 IPv4의 Peering connection을 가르킨다.
    • 0.0.0.0/0 은 당연히 인터넷 게이트웨이를 가르키고 
    • IPv6의 ::/0 egress-only 인터넷 게이트웨이를 가르킨다.
  •