서론
VPC에서의 라우팅에 대해서 약간 정리가 필요한 것 같아 작성한다.
한 가지 주의할 점은, AWS VPC 상에서 라우팅이라고 우리가 온프레미스 환경에서 보는 라우팅과 다르다고 생각하면 안된다는 것이다.
결국 AWS VPC 환경은 온프레미스 네트워크 환경을 모방하여 생성하는 것이기 때문에 근본 원리는 동일하다.
그렇기 때문에 본인이 VPC와 AWS에서의 네트워크를 공부한다면 기본적으로 온프레미스 환경에서의 네트워크 지식을 가지고 있어야 훨씬 수월할 것이다.
문제상황
IPv4 기준으로만 설명한다.
AWS에서 VPC 내부에는 서브넷이 생성된다.
서브넷 안에는 각종 리소스가 생성되어 사용되며, 각 리소스는 ENI를 가진다.
그리고 ENI는 각자 고유한 IP 주소를 부여 받는다.
IP 주소는 서브넷에 설정된 CIDR 내에서 할당 받는다. 그리고 서브넷의 CIDR은 VPC의 CIDR에 속해있다.
VPC => 가상 사설 클라우드 => Private Network
즉, VPC는 내부 IP 대역으로 공인 IP가 아닌 사설 IP를 사용한다.
VPC 내부의 리소스에 할당되는 공인 IP는 각 리소스에 연결되는 ENI에 별도로 할당되며 지금 이야기 하는 사설 IP와는 다른, 실제 인터넷망에서 AWS 리소스로 접근할 수 있는 주소이다.
네트워크를 공부 했다면 사설 IP 대역이 있다는 것을 알고 있을 것이다.
A Class : 10.0.0.0 ~ 10.255.255.255 (10.0.0.0/8)
B Class : 172.16.0.0 ~ 172.31.255.255 (172.16.0.0/12)
C Class : 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)
별개로 127.0.0.0 ~ 127.255.255.255 (127.0.0.0/8) 대역은 Loopback 주소
근데 이 사설 IP 대역은 권고사항이다. 즉, 당신이 원한다면 사설 IP 대역을 위에 적혀있는 대역이 아니라 마음껏 설정해도 된다는 뜻이다.
AWS VPC의 CIDR을 설정할 때도 역시 이는 적용된다.
기본적으로는 사설 IP 대역이 Default 값으로 들어가지만, 본인이 마음대로 IP 대역을 변경할 수 있다.
한가지 예시를 보자.
velog.io 도메인의 IP 주소는 13.209.249.80 이다.
그리고 아래와 같은 VPC 환경이 구성되어 있다 가정한다.
AWS 환경 안에 2개의 VPC가 존재하며, 서로 Peering이 맺어져 있다.
그리고 인터넷에는 velog.io의 서버, 13.209.249.80 주소를 가지는 서버가 존재한다.
VPC 1번의 경우 사설 IP 대역이 할당되어 있으니 큰 문제는 없는데, VPC 2번을 잘 확인해보자.
13.209.0.0/16 CIDR을 가지고 있고 내부 서브넷은 13.209.249.0/24 CIDR을 가진다.
게다가 저 서브넷 안에는 13.209.249.80 사설 IP를 가진 인스턴스가 하나 존재한다.
즉, 지금 velog.io에 할당된 공인 IP 주소와 VPC 2에 생성된 인스턴스의 사설 IP 주소가 동일하다.
13.209.249.80 주소는 Router 1의 라우팅 테이블 2번째와 3번째 규칙에 설정된 대역과 일치한다.
그러면 VPC 1에 있는 172.16.10.100 사설 IP 주소를 가진 인스턴스(물론 공인 IP도 하나 할당되어 있다 가정)가 13.209.249.80 IP 주소로 접근을 시도한다면 어디로 갈까?
2번째와 3번째 규칙 중 어느것을 따라야 하는 것인가?
Longest Prefix Match
이때 적용되는 개념이 바로 Longest Prefix Match 이다.
Longest Prefix Match
그대로 직역하자면 '가장 긴 접두사 일치'
라우터가 IP 패킷을 포워딩(라우팅)할 때 포워딩 테이블에서 해당 항목을 찾는 규칙
IP 패킷의 목적지 IP 주소가 라우팅 테이블에 있는 수많은 목적지 IP 주소 중 일치하는 부분이 가장 긴 곳으로 포워딩(라우팅)하는 규칙이다.
좀 쉽게 말하면 목적지 IP와 라우팅 테이블에 있는 IP 대역이랑 앞에서부터 비트를 비교해서 제일 많이 일치하는 쪽으로 라우팅을 수행하는 것이다.
우리가 아이피를 표기할때 일반적으로 192.168.10.20 같이 10진수로 표기한다.
그런데 컴퓨터는 원래 이진수 기반이다. 내가 좋아하는 말 중 하나가 '컴퓨터는 0 과 1 밖에 모르는 빡대가리' 라는 것이다.
저렇게 10진수로 표기하는것은 우리가 보기 편하자고 해놓은거고 이걸 2진수로 나타내면 다음과 같다.
192.168.10.20 => 11000000.10101000.00001010.00010100
그러면 위에 예시로 한번 어떻게 라우팅 경로가 결정되는지 한번 알아보자.
우선 인스턴스의 IP 주소와 라우팅 테이블 규칙에 10진수로 표기된 IP 주소를 이진수로 바꿔보겠다.
13.209.249.80 => 00001101.11010001.11111001.01010000
172.16.10.100 => 10101100.00010000.00001010.01100100
13.209.0.0/16 => 00001101.11010001.00000000.00000000/16
13.209.249.0/24 => 00001101.11010001.11111001.00000000/24
13.209.249.80/32 => 00001101.11010001.11111001.01010000/32
172.16.0.0/16 => 10101100.00010000.00000000.00000000/16
예제의 상황을 다시 생각해보자.
우리는 VPC 1번 내부에 생성된 172.16.10.100 IP 주소를 가진 인스턴스가 13.209.249.80 주소를 목적지로 트래픽을 보낸다.
인스턴스가 속한 서브넷의 라우팅 테이블인 'Router 1' 을 한번 살펴보자.
-
172.16.0.0/16 => local
목적지 IP와 맞지 않는 대역이다. 따라서 해당 규칙은 무시된다. -
13.209.249.0/24 => igw-123
13.209.249.0/24 대역에는 13.209.249.80 IP 주소가 포함된다.
따라서, 해당 라우팅 규칙을 사용할 수 있다. -
13.209.249.80/32 => pcx-456
13.209.249.80/32 대역에는 13.209.249.80 IP 주소가 포함된다.
따라서, 해당 라우팅 규칙을 사용할 수 있다.
이렇게 2번, 3번 규칙의 IP 대역이 목적지 IP 주소와 일치하는 것을 볼 수 있다.
여기서 Longest Prefix Match를 적용시켜 보자
2번 규칙의 대역은 목적지 IP 주소와 24개의 비트가 동일하다. 뒤에 8자리는 호스트 주소이기 때문에 무시한다.
3번 규칙의 대역은 목적지 IP 주소와 32개의 비트가 동일하다.
그렇기 때문에 우리는 이 트래픽이 3번 규칙에 따라, pcx-456으로 전달되고, VPC 2번에 생성되어 있는 인스턴스에 도달한다는 결론을 얻을 수 있다.
좀더 쉽게 계산하기
1. 라우팅 테이블 규칙을 목적지 대역의 서브넷마스크를 기준으로 내림차순으로 정렬한다.
2. 위에서부터 확인하면서 최초로 일치하는 규칙이 나오면 그 규칙에 의거하여 라우팅을 수행한다.
