클라우드 네트워크 구조: 언더레이·오버레이, 관리망과 VRF 정리

클라우드에서 VPC를 만들고 서브넷과 Security Group을 설정하면 네트워크 구성이 끝난 것처럼 보인다. 그런데 그 VPC가 실제로 어떤 스위치와 회선 위에서 동작하는지는 고객 콘솔 어디에도 나오지 않는다. CSP는 수많은 고객의 네트워크를 같은 물리 장비 위에서 운영하면서 서로 섞이지 않게 분리해야 하고, 그 장비를 관리하는 경로까지 따로 보호해야 한다.

이 글에서는 클라우드 네트워크를 언더레이, 오버레이, 관리망으로 나누어 각각 어떻게 동작하는지 정리했다. VXLAN의 패킷 구조와 VTEP 동작은 이전 글에서 다뤘으므로, 여기서는 클라우드 사업자 관점에서 본 전체 구조에 집중한다.

참고 : VLAN과 VXLAN의 차이, 데이터센터 네트워크는 어떻게 연결될까?

언더레이와 오버레이

언더레이(Underlay)는 CSP 데이터센터의 물리 네트워크다. 서버, 랙 상단의 ToR 스위치, Spine·Leaf 스위치, 라우터, 광회선으로 이루어지며, 물리 호스트끼리 패킷을 빠르고 안정적으로 주고받게 하는 역할을 맡는다. 대규모 데이터센터는 보통 Spine-Leaf 구조 전체를 L3로 구성하고, BGP와 ECMP로 여러 경로를 동시에 사용한다. 언더레이 장비는 패킷이 어느 고객의 것인지 따지지 않고 바깥쪽 호스트 IP만 보고 전달한다.

오버레이(Overlay)는 언더레이 위에 소프트웨어로 만든 고객별 가상 네트워크다. AWS와 GCP의 VPC, Azure의 VNet이 여기에 해당한다. VM이 보낸 원본 패킷을 호스트가 외부 헤더로 감싸 언더레이로 보내고, 목적지 호스트가 헤더를 벗겨 VM에 전달한다. 감싸는 헤더에는 테넌트를 구분하는 식별자가 들어 있어서, 여러 고객이 똑같이 10.0.0.0/16 대역을 써도 충돌하지 않는다.

고객이 콘솔에서 보고 설정하는 네트워크는 모두 오버레이다. 언더레이는 CSP가 운영하며 고객에게 드러나지 않는다. 책임 공유 모델에서 물리 인프라와 가상화 계층을 CSP 책임으로 나누는 것도 이 구조와 맞물려 있다.

두 VPC가 호스트를 공유하고 Leaf와 Spine 물리망을 사용하며 OOB 관리망은 별도 경로로 연결되는 구조

고객은 오버레이만 보고, 호스트 아래 계층과 관리망은 CSP가 운영한다

패킷이 이동하는 과정

같은 VPC 안에서 VM A(10.0.1.5)가 다른 물리 호스트에 있는 VM B(10.0.2.7)로 패킷을 보내는 상황을 생각해보자. VM A가 패킷을 내보내면 호스트 A는 먼저 VM A에 적용된 아웃바운드 정책을 확인한다. 허용된 패킷이라면 VM B가 어느 물리 호스트에 있는지 매핑 정보에서 찾고, 원본 패킷을 감싸 호스트 B의 IP로 보낸다. 언더레이는 이 패킷을 일반 IP 패킷처럼 라우팅한다. 호스트 B는 헤더를 벗긴 뒤 VM B의 인바운드 정책을 확인하고, 허용되면 VM B에 전달한다.

이 과정에서 눈여겨볼 부분은 보안 정책이 적용되는 위치다. Security Group이나 NACL은 네트워크 중간에 놓인 방화벽 장비에서 처리되지 않는다. 패킷이 감싸지기 전과 풀린 직후, 각 호스트의 가상 스위치나 SmartNIC에서 적용된다. 캡슐화는 패킷을 운반하는 수단이고, 통제는 호스트마다 흩어져 있는 정책 적용 지점이 맡는다. 같은 서브넷 안의 VM끼리도 Security Group으로 통신을 막을 수 있는 이유가 여기에 있다.

참고 : CSP 보안에서의 Cloud Firewall과 Security Group

운영할 때도 이 구조를 알고 있으면 도움이 된다. 고객이 VM에서 캡처하는 패킷은 풀린 상태의 원본 패킷이라 외부 헤더는 보이지 않는다. 반대로 AWS VPC Traffic Mirroring처럼 미러링 트래픽을 VXLAN으로 감싸 보내는 기능을 쓰면, 수집 장비에서 디캡슐화 설정을 해야 내용을 분석할 수 있다. 또 캡슐화 헤더만큼 패킷이 커지므로 온프레미스와 VPN이나 GRE로 연결하는 구간에서 MTU와 MSS 문제가 자주 생긴다. 큰 파일 전송만 실패하는 증상이 보이면 이 부분부터 확인하는 편이 빠르다.

CSP별 구현 방식

캡슐화와 정책 적용을 어디서 처리하는지는 CSP마다 다르다. 세부 구현은 대부분 비공개지만, 각 사업자가 논문이나 백서로 공개한 범위에서 정리하면 다음과 같다.

구분	오버레이 처리 위치	공개 자료
AWS	Nitro 카드(하이퍼바이저와 분리된 전용 하드웨어)	Nitro 보안 설계 백서
Azure	모든 호스트에서 동작하는 가상 스위치 VFP(Virtual Filtering Platform)	Microsoft NSDI 2017 논문
GCP	네트워크 가상화 스택 Andromeda(호스트 데이터 플레인과 게이트웨이 조합)	Google NSDI 2018 논문
온프레미스	Leaf 스위치 또는 하이퍼바이저(NSX, Open vSwitch 등)	EVPN-VXLAN 등 표준 문서

Microsoft는 VFP 논문에서 가상 네트워크 터널링, 로드밸런싱용 NAT, 상태 기반 ACL 같은 VM 네트워크 정책을 호스트에서 구현한다고 설명한다. Google도 Andromeda 논문에서 고객 가상 네트워크 간 성능 격리를 주요 설계 요구사항으로 다룬다. 두 사업자 모두 정책과 캡슐화를 각 호스트에서 처리하는 구조라는 점에서 앞에서 본 패킷 흐름과 같다.

온프레미스 데이터센터는 오버레이 제어에 BGP EVPN 같은 표준 프로토콜을 주로 쓴다. 대형 CSP는 목적지 호스트 정보를 자체 매핑 서비스로 관리하는 것으로 알려져 있지만, 이 부분의 세부 구현은 공개 범위가 제한적이다.

관리망의 위치

언더레이 구조를 알고 나면 CSP의 관리망도 언더레이에 있다고 생각하기 쉽다. CSP 내부 관리 트래픽이 고객 오버레이 밖에 있다는 점은 맞지만, 관리 대상에 따라 위치가 나뉜다.

관리 대상	위치	설명
물리 장비 관리(BMC, 스위치 콘솔, 하이퍼바이저 관리)	OOB 관리망	데이터 언더레이 장애 중에도 접근할 수 있도록 별도 구성
언더레이 제어(BGP, 라우팅)	언더레이	스위치와 라우터 사이의 제어 트래픽
오버레이 제어(매핑 정보, 정책 배포)	CSP 내부 제어망	각 호스트의 정책 적용 지점으로 설정 전달
고객용 관리 API와 콘솔	공개 엔드포인트	고객이 접근하는 Management Plane
고객의 관리 영역(Bastion, 관리 서브넷)	고객 오버레이	고객이 직접 설계하고 운영

OOB(Out-of-Band) 관리망은 서비스 트래픽이 흐르는 망과 물리적으로 분리된 관리 전용 네트워크다. 언더레이 장비가 장애로 멈추거나 설정 실수로 경로가 끊겨도 장비 콘솔에 접근해 복구할 수 있어야 하기 때문에 따로 둔다.

AWS는 관리 경로 자체를 줄이는 방향을 택했다. AWS는 Nitro 시스템이 설계상 운영자 접근 수단을 두지 않으며, 운영자가 쓸 수 있는 API로도 EC2 서버의 고객 데이터에 접근할 수 없다고 공개 백서에서 설명한다. 관리망을 잘 분리해 두는 것에서 더 나아가, 사람이 호스트에 로그인할 경로를 처음부터 만들지 않은 설계다.

고객 입장에서 실제로 공격받는 지점은 대부분 표의 아래 두 줄이다. 공격자는 언더레이나 OOB 관리망보다 콘솔과 API 자격증명, IAM 권한을 노린다.

참고 : CSP 관리영역 침해 이후 권한 상승과 수평이동

언더레이의 구역 분리와 VRF

CSP 규모의 언더레이에서 VLAN은 서버와 ToR 스위치 사이처럼 좁은 구간에만 쓰이고, 전체 구조는 L3 라우팅이 중심이 된다. VLAN은 ID가 4,094개로 제한되고 L2 브로드캐스트 범위가 넓어지는 문제가 있어 대규모 멀티테넌시에 맞지 않는다. 언더레이 안에서 관리, 스토리지, 서비스 트래픽처럼 성격이 다른 구역을 나눌 때는 VRF를 많이 쓴다.

VRF(Virtual Routing and Forwarding)는 장비 한 대 안에 서로 독립된 라우팅 테이블을 여러 개 두는 기술이다. VLAN이 L2를 논리적으로 나눈다면 VRF는 L3 라우팅을 나눈다. 인터페이스를 특정 VRF에 할당하면, 그 인터페이스로 들어온 패킷은 해당 VRF의 라우팅 테이블에서만 경로를 찾는다. 그래서 VRF끼리는 기본적으로 통신할 수 없고, 같은 IP 대역을 써도 충돌하지 않는다.

VRF는 쓰이는 환경에 따라 형태가 조금씩 다르다. 기업망에서는 장비 한 대나 인접 장비 사이에서 VRF만으로 구역을 나누는 VRF-Lite를 많이 쓴다. 통신사 백본은 MPLS L3VPN으로 고객별 VRF를 나누고 MP-BGP로 경로를 교환한다. EVPN-VXLAN 데이터센터에서는 테넌트별 VRF를 L3VNI에 연결해 오버레이의 L3 분리를 구현한다.

Cisco IOS 기준으로 VRF를 만들고 인터페이스에 할당하는 설정은 다음과 같다.

vrf definition MGMT
 address-family ipv4
!
interface GigabitEthernet0/1
 vrf forwarding MGMT
 ip address 10.10.0.1 255.255.255.0
!
ip route vrf MGMT 0.0.0.0 0.0.0.0 10.10.0.254

vrf forwarding을 적용하면 해당 인터페이스에 설정된 IP가 지워지므로 IP를 다시 입력해야 한다. 원격으로 작업하면서 지금 접속 중인 인터페이스에 적용하면 연결이 끊기므로 주의한다. 적용 후에는 show ip route vrf MGMT로 라우팅 테이블을, ping vrf MGMT 10.10.0.254로 경로를 확인한다.

VRF는 라우팅을 나눌 뿐 포트나 프로토콜 단위로 통신을 통제하지 않는다. VRF 사이에 경로를 공유하는 라우트 리킹(Route Leaking)이나 RT import/export 설정이 잘못되면 분리가 깨진다. 그래서 VRF 간 통신이 필요하면 리킹보다 방화벽을 경유하도록 설계하는 방식이 일반적이다.

물리 분리와 논리 분리

VRF는 별도 장비가 아니라 L3 스위치, 라우터, 방화벽에 들어 있는 기능이다. 데이터센터 스위치로는 Cisco Nexus 9000, Arista 7000 시리즈, Juniper QFX가 대표적이고, WAN 구간에서는 Cisco ASR이나 Juniper MX 같은 라우터를 쓴다. 방화벽도 Fortinet의 VDOM이나 Palo Alto의 Virtual Router처럼 내부에서 라우팅과 정책 도메인을 나누는 기능을 제공한다. 하이퍼스케일러는 화이트박스 스위치에 SONiC 같은 오픈소스 네트워크 OS를 올려 쓰기도 한다.

장비를 나눌지 고민할 때 Control Plane과 Data Plane을 기준으로 삼으면 방향이 어긋난다. 두 평면은 장비 한 대 안에서 이미 나뉘어 있다. Control Plane은 장비 CPU에서 BGP나 OSPF 같은 프로토콜을 처리하고, Data Plane은 ASIC에서 실제 패킷을 전달한다. 그래서 Control Plane은 장비를 따로 두기보다 CoPP(Control Plane Policing)로 CPU에 올라가는 트래픽을 제한해 보호한다. 물리 분리가 필요한 대상은 장비 관리 접속이 오가는 Management Plane이며, 이를 OOB 관리망으로 떼어내는 것이 표준적인 구성이다.

서비스 구역은 상황에 따라 판단한다. 인터넷과 맞닿은 DMZ와 내부 핵심 업무망처럼 신뢰 수준 차이가 크거나, 국내 금융권처럼 규정이 망분리를 요구하는 경우에는 물리 분리를 검토한다. 장비 한 대가 멈추면 그 위의 모든 VRF가 함께 멈추므로, 장애 영향 범위를 줄여야 하는 서비스도 같은 기준으로 본다. 그 밖의 구역은 VRF와 방화벽을 조합한 논리 분리로 충분한 경우가 많다.

논리 분리를 택할 때는 장비를 공유한다는 점을 함께 고려해야 한다. VRF로 라우팅을 나눠도 OS와 CPU, 관리자 계정은 하나다. 장비 OS 취약점이나 관리자 계정 탈취 한 번이 모든 VRF에 영향을 준다. FortiOS 관리 인터페이스 인증 우회 취약점(CVE-2022-40684)과 PAN-OS 관리 웹 인터페이스 인증 우회 취약점(CVE-2024-0012)은 모두 실제 공격에 악용되었고, 두 제조사 모두 관리 인터페이스에 접근할 수 있는 주소를 제한하도록 권고했다. 관리 인터페이스를 서비스망에 노출하지 않고 패치 주기를 관리하는 일이 논리 분리의 전제 조건이다.

보안 점검 관점

클라우드 네트워크를 점검할 때 고객이 직접 확인하고 통제할 수 있는 범위는 오버레이 설정과 관리 API다. 0.0.0.0/0을 허용한 Security Group, 전이 라우팅을 고려하지 않은 VPC 피어링이나 Transit Gateway 구성, MFA 없이 쓰이는 관리자 계정이 실제 사고로 이어지는 경우가 많다. 언더레이 격리와 OOB 관리망 운영은 고객이 직접 검증할 수 없으므로, SOC 2나 ISO 27001 같은 CSP의 제3자 감사 보고서와 공개 백서로 확인하는 영역이다.

프라이빗 클라우드를 직접 구축해 운영한다면 이 글에서 다룬 계층 전체가 운영 조직의 책임이 된다. 내가 보기에 이때 놓치기 쉬운 부분은 오버레이 정책보다 아래 계층이다. VTEP 대역 접근 통제, VRF 리킹 설정, OOB 관리망 분리, 장비 관리 인터페이스 노출 여부를 오버레이 정책과 같은 비중으로 점검해야 한다.