2020.09.18

제로 트러스트 네트워킹을 향한 한 걸음··· ‘메시 VPN’ 안내서

Lucian Constantin | CSO
메시 버추얼 프라이빗 네트워크에 주목하는 기업이 늘고 있다. 원격 네트워크 연결을 보다 잘 지원하고 안전하도록 만들기 위해서다. 메시(Mesh) VPN은 네트워크의 모든 노드와 피어가 중앙의 집중기나 게이트웨이를 거치지 않고 다른 피어와 직접 연결할 수 있는 P2P(Peer to Peer) 아키텍처를 사용한다. 이 접근방식은 전통적인 VPN보다 비용이 낮고 확장이 쉬울 수 있다.

메시 VPN은 새로운 개념이 아니다. 틈새 용도를 넘어 확장되기까지 오랜 시간이 걸렸을 뿐이다. 몇 년 전만 하더라도 대부분의 조직들은 전통적인 H&S(Hub and Spoke) 아키텍처를 통해 VPN 니즈에 대응했다. 대부분의 기업 방화벽과 게이트웨이 보안 제품에는 VPN 기능이 포함되어 있고, 소수의 직원만이 재택으로 근무하는 환경에 무난히 대응할 수 있었다.

그러나 하이브리드 클라우드 기반 인프라로의 이동과 원격 인력의 확산으로 인해 드디어 메시 네트워킹 솔루션이 등장했다. 다른 클라우드에서 구동 중인 VM과 노드를 연결해야 할 필요성으로 인해 시작됐으며(‘서비스 메시’ 기술), 이제는 확장되어 노트북과 스마트폰 등의 전통적인 종점을 연결하고 있다.

메시 VPN 스타트업 테일스케일(Tailscale)의 CTO 겸 공동 설립자이자 분산형 시스템 및 실험적인 인프라 프로젝트에 참여했던 전직 구글 소프트웨어 엔지니어 데이비드 크러쇼우는 다음과 같이 설명했다.

“이제 서비스 메시와 메시 VPN은 장치들 사이에서 패킷을 안전하고 비밀스럽게 이동하는 문제를 해결할 수 있도록 발전하고 있다. 장기적으로 둘 사이의 차이가 모호해질 것이라고 생각한다. 전통적인 차이점은 장치가 가상(VM 또는 컨테이너) 또는 물리적(스마트폰 또는 노트북 또는 서버)인지 여부였다. 하지만 차이가 점차 모호해지고 있다.”
 
ⓒ Clint Adair (CC0) 

메시 VPN의 인기가 높아지고 있는 이유
코로나19 팬데믹으로 인해 대부분의 기업의 IT 운영이 근본적으로 바뀌면서 거의 하룻밤 사이에 새로운 재택근무 현실에 적응해야 했다. 일부 기업 IT팀들은 이로 인해 기존의 디지털 전환 계획을 가속화하여 재택근무를 지원해야 했으며, 새 솔루션을 찾아 배치하느라 고생한 기업들도 있었다.

실제로 클라우드플레어(Cloudflare), 아카마이(Akamai), 구글 등의 대형 콘텐츠 제공 네트워크 및 클라우드 벤더들은 현재 기업들이 재택 근무자들에게 브라우저를 통해 내부 애플리케이션을 제공하면서 강력한 액세스 관리와 ID 및 보안 점검을 실시할 수 있는 원격 액세스 솔루션을 제공하고 있다. 하지만 한 가지 문제가 있다. 이런 제품의 대부분은 웹 애플리케이션에만 적용되기 때문에 통신을 위해 다른 프로토콜이 필요한 앱과 서비스는 VPN을 통해 액세스해야 한다는 것이다.

전통적으로 VPN 아키텍처는 VPN 게이트웨이가 중앙의 허브이며 모든 클라이언트(스포크)가 연결되는 H&S 모델을 따랐다. VPN 게이트웨이는 서로 연결되어 다중 스포크를 갖춘 다중 허브 디자인을 달성할 수 있다. 오늘날 각 기업 사무실 또는 지사는 저마다 VPN 게이트웨이가 있기 때문에 실제로 이런 구조를 가지는 경우가 많다. 그러나 이는 네트워크 아키텍처의 애로점이 되고 있다.

VPN 연결은 컴퓨팅 집약적인 연산인 암호화를 사용한다. 이로 인해 VPN 게이트웨이는 일정 수의 동시 사용자와 연결을 지원하기 위해 충분한 CPU 성능과 RAM으로 제작됐다. 팬데믹 등과 같은 상황에서 기업이 갑자기 많은 원격 사용자를 지원해야 하는 경우 기업은 VPN 게이트웨이를 더욱 강력한 것으로 완전히 대체하거나 추가적인 VPN 서버를 추가해야 할 수도 있다. 많은 VPN 솔루션에 인원 기준 라이선스 요금이 부과되기 때문에 기업은 추가 라이선스를 구매해야 하기도 한다. 

기업과 VPN 게이트웨이에 제공되는 인터넷 대역폭도 지원 가능한 동시 사용자 수를 제한할 수 있다. 그래서 많은 조직들이 직원들의 인터넷 트래픽 전체를 VPN으로 통과시키지 않는 경우가 많다. 이는 직원들은 안전하지 못한 장소에서 공공 와이파이를 사용하는 결과로 이어지곤 한다.

또 다른 문제는 직원 액세스를 위해 필요한 모든 IT 리소스와 애플리케이션이 해당 기업의 사무실에 구내 방식으로 마련되어 있다는 점이다. 개발 중이거나 공유하고자 하는 앱의 테스트 버전인 경우 이것들을 클라우드의 가상 서버나 동료의 노트북에서 구동할 수 있다.

이런 경우에 사용자는 우선 다른 도시나 지역에 위치하고 있을 수 있는 해당 기업의 VPN 게이트웨이를 거친 후 서버와 VPN 게이트웨이 사이의 VPN 링크를 통해 엔드 서버로 돌아와야 한다. 이로 인해 연결에 지연 속도가 많이 추가되고 성능에 심각한 영향을 받게 된다.

그러나 P2P 메시 VPN에서는 중앙의 집중기나 게이트웨이 없이 모든 노드가 다른 피어와 직접 연결할 수 있다. 인터넷이 본래 설계된 방식이기도 하다. 조직들과 사용자들은 단지 네트워크에 추가적인 노드를 추가하면 된다. 

메시 VPN의 작동 방식
시간이 지나면서 인터넷은 고속 인터넷 교환점에서 서로 연결되어 있는 티어1 통신기업, 클라우드 벤더, 콘텐츠 제공 네트워크로 구성된 백본을 발전시켰다. 또한 제한된 공개 IPv4 주소 풀로 인해 ISP 수준을 포함하여 NAT을 더 많이 활용하게 되면서 인터넷은 점차 H&S 아키텍처를 닮게 되었다. IPv6 지지자들이 원하는 바이기도 하다.

일부 하드웨어 VPN 게이트웨이는 다중 지점간 구성을 지원하며 메시 네트워크와 유사하게 작동할 수 있기는 하다. 그러나 구성을 지속적으로 관리하고 클라이언트 및 노드에 변경사항이 발생하면 업데이트해야 한다. 서비스와 앱을 여러 클라이언트의 VM으로 구동하는 세상에서는 이런 일이 꽤 자주 발생한다.

크러쇼우는 “네트워크들이 계속 재배열된다. VM들이 데이터 센터들 사이에서 이동하고 스마트폰들이 사무실들 사이에서 이동하게 된다. 기업은 30년 동안 사무실을 보유하고 전용 네트워크 하드웨어를 구내로 구축하거나 사무실을 월 단위로 임대할 수 있다. ‘메시’라는 용어가 사용될 때는 자동 종점 구성을 의미하는 경우가 많다. 즉, 네트워크상에서 장치를 이동하면 IT 관리자의 개입 없이 메시 네트워크상의 다른 장치와 다시 통신해야 한다”라고 말했다.

메시VPN은 소프트웨어를 통해 실행된다는 점에서 SDN(Software-defined Network)이다. 물론 시중의 SD-WAN 개념은 대규모 데이터 센터 및 통신 인프라 프로젝트에서 전통적인 네트워킹 장비의 중앙 관리 및 통제를 간소화하고 자동화하기 위해 고안된 솔루션을 의미한다.

인기 솔루션
메시 네트워크를 위해 고안된 최초의 오픈소스 데몬(Daemon)은 1989년 등장한 'Tinc VPN'이다. 윈도우, 리눅스, BSD, 맥OS 등 거의 모든 주요 운영체제에서 작동하며 자동 전체 메시 라우팅, NAT 횡단, 이더넷 세그먼트 연결을 지원한다. Tinc는 이후의 여러 프로젝트에 영감을 줬다.

상업적 기업이 지지하고 있는 더 새로운 오픈소스 메시 VPN 솔루션은 제로티어(ZeroTier)이며 2015년에 개발됐다. 제로티어는 스스로 로컬 네트워크 또는 인터넷에 분산되어 있는 앱 및 장치로 구성된 P2P 네트워크에 상주하며 이를 통제하는 기업용 SDN 스위치의 기능의 대부분을 갖춘 ‘지구를 위한 프로그래밍 가능한 스마트 이더넷 스위치’라고 설명한다. 

그 결과, 향상된 관리 및 모니터링 기능, 자동 피어 발견 및 구성, 사용자 정의 프로토콜을 통한 트래픽 암호화를 제공하는 네트워크 하이퍼바이저를 갖춘 메시 VPN이 탄생했다.

지난해, 슬랙의 소프트웨어 엔지니어들은 NPF(Noise Protocol Framework)를 기반으로 개발된 또 다른 오픈소스 메시 VPN 프로젝트인 네뷸라(Nebula)를 공개했다. 그들은 네뷸라를 전 세계 여러 곳에서 여러 클라우드 서비스 제공자에서 구동 중인 수 천 개의 노드를 연결할 수 있는 상호 인증 P2P 소프트웨어 정의 네트워크를 구축하기 위해 고안된 ‘확장형 오버레이 네트워킹 도구’라고 말한다. 네뷸라는 인증기관이 발행한 인증서를 사용하여 노드뿐 아니라 IP주소, 이름, 사용자 정의 그룹 내의 멤버십 같은 속성을 확인한다.

슬랙의 엔지니어들이 네뷸라 발표 때 다음과 같이 설명했다.

“대부분의 클라우드 제공자는 사용자가 IP 주소나 범위에 의한 개별적인 방법과는 달리 그룹 멤버십에 기초하여 네트워크 트래픽을 필터링할 수 있는 ‘보안 그룹’이라는 특정 형태의 사용자 정의 네트워크 호스트 그룹핑을 제공한다. 안타깝게도 현재 보안 그룹은 각 호스팅 제공자 지역으로 구분되어 있다. 또한 여러 호스팅 제공자들 사이에서 상호 운용이 가능한 보안 그룹 버전도 없다.”

“즉, 여러 지역 또는 제공자로 확장하면서 유일하게 유용한 옵션이 IP주소 또는 IP네트워크 범위에 의한 네트워크 분할이 되는 것이며, 이것은 관리하기가 복잡하다. 우리의 요구사항과 우리의 암호화, 분할, 운영 요구사항을 충족할 수 있는 기성 옵션의 부재를 고려하여 자체 솔루션을 개발하기로 결정했다.”

이 분야에 진입한 다른 주체로는 올 해 리눅스와 OpenBSD 커널에 적용된 새로운 고성능 와이어가드 VPN(WireGuard VPN) 프로토콜을 중심으로 구축된 크러쇼우의 테일스케일(Tailscale)이 있다. 테일스케일은 아직 와이어가드 커널 코드를 사용하지 않지만 Go 프로그래밍 언어로 작성된 프로토콜의 사용자 공간 구현은 현재 윈도우, 리눅스, 맥OS, iOS, 안드로이드에서 적용할 수 있다.

테일스케일의 코드의 대부분은 오픈소스이며 비즈니스 모델은 자동 피어 발견 및 구성에 사용되는 중앙 디렉토리 서비스 또는 조정 노드를 구동하는 것이 중심이 되며 관리자가 역할 기반 액세스 관리 및 로깅을 관리할 수 있다. 대기업 배치의 경우 테일스케일은 구내 조정 서버를 구동하는 옵션을 제공하지만 전통적인 VPN 게이트웨이와는 달리 이런 서버를 통과하는 실제 사용자 트래픽은 없다. 단지 구성 정보를 교환하기 위한 용도로만 사용된다.

ID 및 제로트러스트 네트워크
제로트러스트 네트워킹은 기업 네트워크의 미래로 여겨지곤 한다. 이것은 신뢰하고 기업 리소스에 대한 액세스를 부여하기 전에 모든 사용자와 장치의 ID를 검증하는 아키텍처이다. 대부분의 전통적인 기업 네트워크에서는 내부 네트워크에 위치한 장치가 동일한 명시적으로 ‘신뢰할 수 있는’ 네트워크에 있다는 이유만으로 서버와 서비스에 연결할 수 있으며, 이 때문에 해커들이 그렇게 네트워크를 통해 횡방향으로 이동할 수 있다.

대부분의 메시 VPN 솔루션은 구글의 'BeyondCorp 프로젝트'와 기타 제로트러스트 네트워킹 개념에서 영감을 얻었으며 장치 또는 노드 ID 검증에 크게 집중한다. 제로티어, 네뷸라, 테일스케일에서 노드 ID는 일정 형태의 공개키 암호화를 통해 IP 계층에서 이뤄진다.

크러쇼우는 “전통적인 물리 네트워크는 ID에 대한 개념을 제공하지 않는다. 우리는 그 아이디어에 너무 익숙해서 ID를 네트워크 트래픽에 적용하는 현대적인 작업은 항상 더 높은 수준의 추상화(HTTPS/TLS 등)에서 시작됐다”라고 말했다. 

하지만 꼭 그럴 필요는 없다. 네트워크 터널과 현대의 암호화를 사용하여 패킷의 IP 소스 주소가 전송 주체를 정확하게 설명할 수 있도록 한다. 이 개념을 IP계층으로 이동할 때의 장점은 기존의 소프트웨어와 호환된다는 점이다. 기존의 내부 도구를 가져다가 모든 전송자와 수신자의 ID가 알려져 있는 사설 가상 네트워크로 이동하여 전통적인 네트워크를 통한 액세스를 서서히 차단할 수 있다. ID를 인식하기 위해 모든 소프트웨어를 다시 작성할 필요가 없다.

와이어가드 프로토콜의 경우 한 노드의 공개 키를 해당 노드가 내부 VPN 터널을 가질 수 있는 IP 주소 목록에 연계시키는 암호 키 라우팅의 개념을 도입한다. 즉, 노드의 사설 키가 보호된다면 네트워크상에서 노드 사칭의 가능성이 없다. 이를 통해 네트워크 관리자와 보안팀은 메시 네트워크에서 특정 애플리케이션이나 리소스를 특정 장치와 사용자에게만 표시하고 액세스를 허용할 수 있다.

프로토콜 수준에서 수행되는 장치ID 확인 외에도 메시 VPN은 사용자 ID 확인을 수행할 수 있다. 예를 들어, 테일스케일은 이미 구글, 마이크로소프트, 옥타, SAP 등이 사용하고 있는 가장 보편적인 ID 제공자와의 통합을 지원하며 이것을 통한 다중 인증을 지원한다.

또한 기업들은 웹 애플리케이션 액세스를 위해 비 HTTP 애플리케이션과 서비스에 액세스하기 위한 메시 VPN 솔루션을 아카마이, 클라우드플레어, 구글 등이 제공하는 제로트러스트 액세스 게이트웨이와 결합할 수 있다. 이런 솔루션은 또한 브라우저 또는 종점에 설치된 별도의 가벼운 클라이언트를 통한 장치 보안 확인도 수행한다. ciokr@idg.co.kr



2020.09.18

제로 트러스트 네트워킹을 향한 한 걸음··· ‘메시 VPN’ 안내서

Lucian Constantin | CSO
메시 버추얼 프라이빗 네트워크에 주목하는 기업이 늘고 있다. 원격 네트워크 연결을 보다 잘 지원하고 안전하도록 만들기 위해서다. 메시(Mesh) VPN은 네트워크의 모든 노드와 피어가 중앙의 집중기나 게이트웨이를 거치지 않고 다른 피어와 직접 연결할 수 있는 P2P(Peer to Peer) 아키텍처를 사용한다. 이 접근방식은 전통적인 VPN보다 비용이 낮고 확장이 쉬울 수 있다.

메시 VPN은 새로운 개념이 아니다. 틈새 용도를 넘어 확장되기까지 오랜 시간이 걸렸을 뿐이다. 몇 년 전만 하더라도 대부분의 조직들은 전통적인 H&S(Hub and Spoke) 아키텍처를 통해 VPN 니즈에 대응했다. 대부분의 기업 방화벽과 게이트웨이 보안 제품에는 VPN 기능이 포함되어 있고, 소수의 직원만이 재택으로 근무하는 환경에 무난히 대응할 수 있었다.

그러나 하이브리드 클라우드 기반 인프라로의 이동과 원격 인력의 확산으로 인해 드디어 메시 네트워킹 솔루션이 등장했다. 다른 클라우드에서 구동 중인 VM과 노드를 연결해야 할 필요성으로 인해 시작됐으며(‘서비스 메시’ 기술), 이제는 확장되어 노트북과 스마트폰 등의 전통적인 종점을 연결하고 있다.

메시 VPN 스타트업 테일스케일(Tailscale)의 CTO 겸 공동 설립자이자 분산형 시스템 및 실험적인 인프라 프로젝트에 참여했던 전직 구글 소프트웨어 엔지니어 데이비드 크러쇼우는 다음과 같이 설명했다.

“이제 서비스 메시와 메시 VPN은 장치들 사이에서 패킷을 안전하고 비밀스럽게 이동하는 문제를 해결할 수 있도록 발전하고 있다. 장기적으로 둘 사이의 차이가 모호해질 것이라고 생각한다. 전통적인 차이점은 장치가 가상(VM 또는 컨테이너) 또는 물리적(스마트폰 또는 노트북 또는 서버)인지 여부였다. 하지만 차이가 점차 모호해지고 있다.”
 
ⓒ Clint Adair (CC0) 

메시 VPN의 인기가 높아지고 있는 이유
코로나19 팬데믹으로 인해 대부분의 기업의 IT 운영이 근본적으로 바뀌면서 거의 하룻밤 사이에 새로운 재택근무 현실에 적응해야 했다. 일부 기업 IT팀들은 이로 인해 기존의 디지털 전환 계획을 가속화하여 재택근무를 지원해야 했으며, 새 솔루션을 찾아 배치하느라 고생한 기업들도 있었다.

실제로 클라우드플레어(Cloudflare), 아카마이(Akamai), 구글 등의 대형 콘텐츠 제공 네트워크 및 클라우드 벤더들은 현재 기업들이 재택 근무자들에게 브라우저를 통해 내부 애플리케이션을 제공하면서 강력한 액세스 관리와 ID 및 보안 점검을 실시할 수 있는 원격 액세스 솔루션을 제공하고 있다. 하지만 한 가지 문제가 있다. 이런 제품의 대부분은 웹 애플리케이션에만 적용되기 때문에 통신을 위해 다른 프로토콜이 필요한 앱과 서비스는 VPN을 통해 액세스해야 한다는 것이다.

전통적으로 VPN 아키텍처는 VPN 게이트웨이가 중앙의 허브이며 모든 클라이언트(스포크)가 연결되는 H&S 모델을 따랐다. VPN 게이트웨이는 서로 연결되어 다중 스포크를 갖춘 다중 허브 디자인을 달성할 수 있다. 오늘날 각 기업 사무실 또는 지사는 저마다 VPN 게이트웨이가 있기 때문에 실제로 이런 구조를 가지는 경우가 많다. 그러나 이는 네트워크 아키텍처의 애로점이 되고 있다.

VPN 연결은 컴퓨팅 집약적인 연산인 암호화를 사용한다. 이로 인해 VPN 게이트웨이는 일정 수의 동시 사용자와 연결을 지원하기 위해 충분한 CPU 성능과 RAM으로 제작됐다. 팬데믹 등과 같은 상황에서 기업이 갑자기 많은 원격 사용자를 지원해야 하는 경우 기업은 VPN 게이트웨이를 더욱 강력한 것으로 완전히 대체하거나 추가적인 VPN 서버를 추가해야 할 수도 있다. 많은 VPN 솔루션에 인원 기준 라이선스 요금이 부과되기 때문에 기업은 추가 라이선스를 구매해야 하기도 한다. 

기업과 VPN 게이트웨이에 제공되는 인터넷 대역폭도 지원 가능한 동시 사용자 수를 제한할 수 있다. 그래서 많은 조직들이 직원들의 인터넷 트래픽 전체를 VPN으로 통과시키지 않는 경우가 많다. 이는 직원들은 안전하지 못한 장소에서 공공 와이파이를 사용하는 결과로 이어지곤 한다.

또 다른 문제는 직원 액세스를 위해 필요한 모든 IT 리소스와 애플리케이션이 해당 기업의 사무실에 구내 방식으로 마련되어 있다는 점이다. 개발 중이거나 공유하고자 하는 앱의 테스트 버전인 경우 이것들을 클라우드의 가상 서버나 동료의 노트북에서 구동할 수 있다.

이런 경우에 사용자는 우선 다른 도시나 지역에 위치하고 있을 수 있는 해당 기업의 VPN 게이트웨이를 거친 후 서버와 VPN 게이트웨이 사이의 VPN 링크를 통해 엔드 서버로 돌아와야 한다. 이로 인해 연결에 지연 속도가 많이 추가되고 성능에 심각한 영향을 받게 된다.

그러나 P2P 메시 VPN에서는 중앙의 집중기나 게이트웨이 없이 모든 노드가 다른 피어와 직접 연결할 수 있다. 인터넷이 본래 설계된 방식이기도 하다. 조직들과 사용자들은 단지 네트워크에 추가적인 노드를 추가하면 된다. 

메시 VPN의 작동 방식
시간이 지나면서 인터넷은 고속 인터넷 교환점에서 서로 연결되어 있는 티어1 통신기업, 클라우드 벤더, 콘텐츠 제공 네트워크로 구성된 백본을 발전시켰다. 또한 제한된 공개 IPv4 주소 풀로 인해 ISP 수준을 포함하여 NAT을 더 많이 활용하게 되면서 인터넷은 점차 H&S 아키텍처를 닮게 되었다. IPv6 지지자들이 원하는 바이기도 하다.

일부 하드웨어 VPN 게이트웨이는 다중 지점간 구성을 지원하며 메시 네트워크와 유사하게 작동할 수 있기는 하다. 그러나 구성을 지속적으로 관리하고 클라이언트 및 노드에 변경사항이 발생하면 업데이트해야 한다. 서비스와 앱을 여러 클라이언트의 VM으로 구동하는 세상에서는 이런 일이 꽤 자주 발생한다.

크러쇼우는 “네트워크들이 계속 재배열된다. VM들이 데이터 센터들 사이에서 이동하고 스마트폰들이 사무실들 사이에서 이동하게 된다. 기업은 30년 동안 사무실을 보유하고 전용 네트워크 하드웨어를 구내로 구축하거나 사무실을 월 단위로 임대할 수 있다. ‘메시’라는 용어가 사용될 때는 자동 종점 구성을 의미하는 경우가 많다. 즉, 네트워크상에서 장치를 이동하면 IT 관리자의 개입 없이 메시 네트워크상의 다른 장치와 다시 통신해야 한다”라고 말했다.

메시VPN은 소프트웨어를 통해 실행된다는 점에서 SDN(Software-defined Network)이다. 물론 시중의 SD-WAN 개념은 대규모 데이터 센터 및 통신 인프라 프로젝트에서 전통적인 네트워킹 장비의 중앙 관리 및 통제를 간소화하고 자동화하기 위해 고안된 솔루션을 의미한다.

인기 솔루션
메시 네트워크를 위해 고안된 최초의 오픈소스 데몬(Daemon)은 1989년 등장한 'Tinc VPN'이다. 윈도우, 리눅스, BSD, 맥OS 등 거의 모든 주요 운영체제에서 작동하며 자동 전체 메시 라우팅, NAT 횡단, 이더넷 세그먼트 연결을 지원한다. Tinc는 이후의 여러 프로젝트에 영감을 줬다.

상업적 기업이 지지하고 있는 더 새로운 오픈소스 메시 VPN 솔루션은 제로티어(ZeroTier)이며 2015년에 개발됐다. 제로티어는 스스로 로컬 네트워크 또는 인터넷에 분산되어 있는 앱 및 장치로 구성된 P2P 네트워크에 상주하며 이를 통제하는 기업용 SDN 스위치의 기능의 대부분을 갖춘 ‘지구를 위한 프로그래밍 가능한 스마트 이더넷 스위치’라고 설명한다. 

그 결과, 향상된 관리 및 모니터링 기능, 자동 피어 발견 및 구성, 사용자 정의 프로토콜을 통한 트래픽 암호화를 제공하는 네트워크 하이퍼바이저를 갖춘 메시 VPN이 탄생했다.

지난해, 슬랙의 소프트웨어 엔지니어들은 NPF(Noise Protocol Framework)를 기반으로 개발된 또 다른 오픈소스 메시 VPN 프로젝트인 네뷸라(Nebula)를 공개했다. 그들은 네뷸라를 전 세계 여러 곳에서 여러 클라우드 서비스 제공자에서 구동 중인 수 천 개의 노드를 연결할 수 있는 상호 인증 P2P 소프트웨어 정의 네트워크를 구축하기 위해 고안된 ‘확장형 오버레이 네트워킹 도구’라고 말한다. 네뷸라는 인증기관이 발행한 인증서를 사용하여 노드뿐 아니라 IP주소, 이름, 사용자 정의 그룹 내의 멤버십 같은 속성을 확인한다.

슬랙의 엔지니어들이 네뷸라 발표 때 다음과 같이 설명했다.

“대부분의 클라우드 제공자는 사용자가 IP 주소나 범위에 의한 개별적인 방법과는 달리 그룹 멤버십에 기초하여 네트워크 트래픽을 필터링할 수 있는 ‘보안 그룹’이라는 특정 형태의 사용자 정의 네트워크 호스트 그룹핑을 제공한다. 안타깝게도 현재 보안 그룹은 각 호스팅 제공자 지역으로 구분되어 있다. 또한 여러 호스팅 제공자들 사이에서 상호 운용이 가능한 보안 그룹 버전도 없다.”

“즉, 여러 지역 또는 제공자로 확장하면서 유일하게 유용한 옵션이 IP주소 또는 IP네트워크 범위에 의한 네트워크 분할이 되는 것이며, 이것은 관리하기가 복잡하다. 우리의 요구사항과 우리의 암호화, 분할, 운영 요구사항을 충족할 수 있는 기성 옵션의 부재를 고려하여 자체 솔루션을 개발하기로 결정했다.”

이 분야에 진입한 다른 주체로는 올 해 리눅스와 OpenBSD 커널에 적용된 새로운 고성능 와이어가드 VPN(WireGuard VPN) 프로토콜을 중심으로 구축된 크러쇼우의 테일스케일(Tailscale)이 있다. 테일스케일은 아직 와이어가드 커널 코드를 사용하지 않지만 Go 프로그래밍 언어로 작성된 프로토콜의 사용자 공간 구현은 현재 윈도우, 리눅스, 맥OS, iOS, 안드로이드에서 적용할 수 있다.

테일스케일의 코드의 대부분은 오픈소스이며 비즈니스 모델은 자동 피어 발견 및 구성에 사용되는 중앙 디렉토리 서비스 또는 조정 노드를 구동하는 것이 중심이 되며 관리자가 역할 기반 액세스 관리 및 로깅을 관리할 수 있다. 대기업 배치의 경우 테일스케일은 구내 조정 서버를 구동하는 옵션을 제공하지만 전통적인 VPN 게이트웨이와는 달리 이런 서버를 통과하는 실제 사용자 트래픽은 없다. 단지 구성 정보를 교환하기 위한 용도로만 사용된다.

ID 및 제로트러스트 네트워크
제로트러스트 네트워킹은 기업 네트워크의 미래로 여겨지곤 한다. 이것은 신뢰하고 기업 리소스에 대한 액세스를 부여하기 전에 모든 사용자와 장치의 ID를 검증하는 아키텍처이다. 대부분의 전통적인 기업 네트워크에서는 내부 네트워크에 위치한 장치가 동일한 명시적으로 ‘신뢰할 수 있는’ 네트워크에 있다는 이유만으로 서버와 서비스에 연결할 수 있으며, 이 때문에 해커들이 그렇게 네트워크를 통해 횡방향으로 이동할 수 있다.

대부분의 메시 VPN 솔루션은 구글의 'BeyondCorp 프로젝트'와 기타 제로트러스트 네트워킹 개념에서 영감을 얻었으며 장치 또는 노드 ID 검증에 크게 집중한다. 제로티어, 네뷸라, 테일스케일에서 노드 ID는 일정 형태의 공개키 암호화를 통해 IP 계층에서 이뤄진다.

크러쇼우는 “전통적인 물리 네트워크는 ID에 대한 개념을 제공하지 않는다. 우리는 그 아이디어에 너무 익숙해서 ID를 네트워크 트래픽에 적용하는 현대적인 작업은 항상 더 높은 수준의 추상화(HTTPS/TLS 등)에서 시작됐다”라고 말했다. 

하지만 꼭 그럴 필요는 없다. 네트워크 터널과 현대의 암호화를 사용하여 패킷의 IP 소스 주소가 전송 주체를 정확하게 설명할 수 있도록 한다. 이 개념을 IP계층으로 이동할 때의 장점은 기존의 소프트웨어와 호환된다는 점이다. 기존의 내부 도구를 가져다가 모든 전송자와 수신자의 ID가 알려져 있는 사설 가상 네트워크로 이동하여 전통적인 네트워크를 통한 액세스를 서서히 차단할 수 있다. ID를 인식하기 위해 모든 소프트웨어를 다시 작성할 필요가 없다.

와이어가드 프로토콜의 경우 한 노드의 공개 키를 해당 노드가 내부 VPN 터널을 가질 수 있는 IP 주소 목록에 연계시키는 암호 키 라우팅의 개념을 도입한다. 즉, 노드의 사설 키가 보호된다면 네트워크상에서 노드 사칭의 가능성이 없다. 이를 통해 네트워크 관리자와 보안팀은 메시 네트워크에서 특정 애플리케이션이나 리소스를 특정 장치와 사용자에게만 표시하고 액세스를 허용할 수 있다.

프로토콜 수준에서 수행되는 장치ID 확인 외에도 메시 VPN은 사용자 ID 확인을 수행할 수 있다. 예를 들어, 테일스케일은 이미 구글, 마이크로소프트, 옥타, SAP 등이 사용하고 있는 가장 보편적인 ID 제공자와의 통합을 지원하며 이것을 통한 다중 인증을 지원한다.

또한 기업들은 웹 애플리케이션 액세스를 위해 비 HTTP 애플리케이션과 서비스에 액세스하기 위한 메시 VPN 솔루션을 아카마이, 클라우드플레어, 구글 등이 제공하는 제로트러스트 액세스 게이트웨이와 결합할 수 있다. 이런 솔루션은 또한 브라우저 또는 종점에 설치된 별도의 가벼운 클라이언트를 통한 장치 보안 확인도 수행한다. ciokr@idg.co.kr

X