클라우드 네트워크

01

클라우드 안에 내 네트워크 만들기: 가상 네트워크와 IP 대역

클라우드 데이터센터에는 수많은 고객의 서버가 함께 돌아갑니다. 그래도 내 서버끼리만 통하고 다른 고객과는 갈라져 있어야 합니다. 그래서 클라우드는 고객마다 논리적으로 분리된 네트워크를 만들어 줍니다. 이것을 가상 네트워크라고 합니다. 실제 케이블과 스위치는 공유하지만, 주소와 경로와 규칙은 고객마다 따로입니다.

가상 네트워크를 만들 때 가장 먼저 정하는 것이 사용할 IP 주소의 범위(대역)입니다. 보통 인터넷에서 쓰지 않기로 약속된 사설 대역 안에서 고릅니다. 사설 대역은 회사마다, 집집마다 겹쳐 써도 되는 주소라서 인터넷으로 바로 나가지는 못합니다(어떻게 나가는지는 3장에서 봅니다).

CIDR: 슬래시 뒤 숫자 읽기

IPv4 주소는 32비트입니다. 10.0.0.0/16은 "앞 16비트(10.0)는 고정하고 나머지 16비트를 이 네트워크가 쓴다"는 뜻입니다. 그래서 주소는 2^16 = 65,536개입니다. / 뒤 숫자가 클수록 고정하는 부분이 길어져 대역이 작아집니다. 이 표기를 CIDR이라고 합니다. 아래 그림에서 서브넷 크기를 바꿔 보세요.

가상 네트워크의 대역은 다시 서브넷으로 나눕니다. 서브넷은 같은 성격의 서버를 모아 두는 구역입니다. 인터넷에 보일 웹 계층, 숨겨 둘 DB 계층처럼 역할별로 나누고, 서브넷마다 다른 경로(2장)와 방화벽(4장)을 걸 수 있습니다.

서브넷의 주소를 다 쓸 수는 없다

서브넷마다 클라우드가 미리 잡아 두는 주소가 있습니다. 서브넷의 첫 주소(네트워크 주소), 서브넷 밖으로 나가는 문인 게이트웨이, DNS 같은 것들입니다. 몇 개를 잡아 두는지는 클라우드 프로바이더마다 다릅니다. 그래서 /24 서브넷이라도 서버에 줄 수 있는 주소는 256개보다 조금 적습니다.

처음부터 넉넉하게, 겹치지 않게

대역은 만든 뒤 바꾸기 어렵습니다. 서버와 서비스가 늘 것을 생각해 넉넉하게 잡고, 사내망이나 다른 가상 네트워크와 겹치지 않게 나눠 둡니다. 사내망이 192.168.0.0/16을 쓰는데 클라우드도 같은 대역을 쓰면, 나중에 둘을 이으려 할 때 어느 쪽 192.168.1.10인지 가릴 수 없어 연결 자체가 안 됩니다(7장).

대역을 나눠 서브넷을 만들었습니다. 그런데 서브넷의 서버가 보낸 패킷은 어디로 갈지 어떻게 알까요?

02

서브넷과 라우팅: 퍼블릭과 프라이빗을 가르는 것

서버가 패킷을 보내면 서브넷에 연결된 라우트 테이블이 갈 길을 정합니다. 라우트 테이블은 "이 대역으로 가는 패킷은 저 문으로 보낸다"는 줄의 목록입니다. 가상 네트워크에는 "네트워크 안의 주소는 네트워크 안에서 전달한다"는 기본 경로가 처음부터 있어서, 서브넷끼리는 따로 설정하지 않아도 통신합니다.

목적지            다음 홉(보낼 곳)
10.0.0.0/16       네트워크 안 (로컬)
172.16.0.0/12     VPN 연결 → 사내망
0.0.0.0/0         인터넷 게이트웨이

라우트 테이블은 패킷의 목적지 주소가 들어맞는 줄을 찾아 그 줄의 다음 홉으로 보냅니다. 예를 들어 웹 서버가 같은 네트워크에 있는 DB 서버(10.0.2.15)로 패킷을 보낸다고 해 봅시다. 10.0.2.15는 10.0.0.0/16 안의 주소이니 첫 줄에 맞습니다. 그런데 0.0.0.0/0은 "모든 주소"라서 마지막 줄에도 맞습니다.

이렇게 여러 줄이 맞을 때는 가장 구체적인 줄, 즉 / 뒤 숫자가 큰 줄이 이깁니다(최장 접두사 일치). /16이 /0보다 구체적이니 이 패킷은 네트워크 안에서 전달됩니다. 반면 인터넷의 웹사이트(203.0.113.10)는 앞의 두 줄에 맞지 않고 0.0.0.0/0에만 맞아 인터넷 게이트웨이로 갑니다. 그래서 0.0.0.0/0을 다른 어떤 줄에도 맞지 않는 주소가 마지막에 가는 곳, 기본 경로라고 부릅니다. 아래 그림에서 목적지와 서브넷 종류를 바꿔 보세요.

퍼블릭 서브넷과 프라이빗 서브넷

인터넷 쪽으로 가는 경로(0.0.0.0/0 → 인터넷)가 있는 서브넷을 퍼블릭 서브넷, 없는 서브넷을 프라이빗 서브넷이라고 부릅니다. 서브넷에 붙인 이름이 아니라 경로가 정합니다. 퍼블릭 서브넷이라도 서버가 인터넷과 직접 주고받으려면 서버에 공인 IP가 있어야 합니다. 사설 IP만 가진 서버는 퍼블릭 서브넷에 있어도 인터넷에서 찾아올 수 없습니다.

흔한 웹 서비스는 이렇게 나눕니다.

DB와 앱 서버를 프라이빗 서브넷에 숨겼습니다. 그런데 이 서버들도 보안 업데이트는 받아야 하고, 같은 클라우드의 저장소 서비스에도 접근해야 합니다. 인터넷 경로가 없는데 어떻게 나갈까요?

03

프라이빗 서브넷에서 밖으로 나가기: NAT와 사설 엔드포인트

NAT(Network Address Translation, 주소 변환)는 프라이빗 서버의 대리인입니다. 서버가 인터넷으로 보낸 패킷의 출발지 주소를 NAT 자신의 공인 IP로 바꿔 내보내고, 응답이 오면 누가 보낸 요청이었는지 기억해 둔 대로 원래 서버에게 돌려줍니다.

핵심은 방향입니다. NAT는 안에서 시작한 연결만 대신해 줍니다. 밖에서 먼저 들어오려는 연결은 누구에게 보낼지 모르니 받지 않습니다. 그래서 "서버가 업데이트는 받아야 하지만 인터넷에서 접속되면 안 된다"는 문제의 답이 NAT입니다. 반대로 인터넷에서 서버로 요청을 받으려면 로드 밸런서(5장)나 서버의 공인 IP가 필요합니다.

NAT는 대개 클라우드가 관리해 주는 서비스로 씁니다. 서버 한 대를 NAT로 직접 꾸미는 방법도 있지만, 그 서버가 죽으면 프라이빗 서브넷 전체가 밖으로 못 나가니 고가용성과 관리 부담을 따로 챙겨야 합니다. 관리형 NAT를 어느 범위(영역 하나, 리전 전체)에 두는지는 프로바이더마다 다릅니다.

인터넷을 거치지 않고 클라우드 서비스에 닿기: 사설 엔드포인트

저장소, 큐, 키 관리 같은 클라우드의 관리형 서비스는 보통 인터넷 쪽 공개 주소를 가집니다. 프라이빗 서버가 그냥 부르면 NAT를 지나 인터넷 쪽으로 나갔다가 들어옵니다. 사설 엔드포인트를 두면 그 길이 네트워크 안에서 끝납니다. 방식은 두 가지입니다.

이제 패킷이 갈 길은 정해졌습니다. 하지만 길이 있다고 아무나 지나가게 둘 수는 없습니다. 어떤 패킷을 들여보내고 막을지 정하는 문지기가 필요합니다.