WARP Connector 소개: 무제한 연결로의 여정

끊임없이 진화하는 기업 보안 영역에서 CISO 와 CIO는 우수한 성능의 무제한 연결을 달성하기 위해 새로운 기업 네트워크를 끊임없이 구축하고 기존의 네트워크를 유지해야 합니다. 네트워크 설계자로 구성된 팀의 경우, 변화하는 요구 사항에 대응하기 위해 자체 환경을 조사하는 것은 전체 작업의 절반 정도를 차지합니다. 나머지 절반은, 기존의 환경에 원활하게 통합할 수 있는 새롭고 혁신적인 솔루션을 발굴하는 작업인 경우가 많습니다. 안전하고 유연한 인프라를 추구하기 위한 이러한 지속적인 구축 및 강화 주기야 말로 Cloudflare의 SASE 제품인 Cloudflare One이 구축된 이유입니다.

Cloudflare One은 고객과 분석가의 피드백을 기반으로 지속해서 발전해 왔습니다.  오늘, Cloudflare WARP Connector의 가용성을 발표하게 되어 기쁩니다. 이 도구는 기존 네트워크 인프라를 중단시킬 필요 없이 양방향, 사이트 간, 메시형 연결을 훨씬 더 쉽게 보호할 수 있게 해줍니다.

Cloudflare에서는 항상 광범위한 제품을 제공하는 데 중점을 두며, 네트워크 연결에 대해 하나로 모든 것이 해결되는 솔루션은 없다는 점을 인정합니다. Cloudflare의 비전은 간단합니다. 원하는 방식으로 무제한 연결하는 것입니다.

WARP Connector 이전에는 로컬 HTTP 서버, 쿠버네티스 클러스터가 제공하는 웹 서비스, 사설 네트워크 세그먼트 등의 인프라를 Cloudflare에 연결하는 가장 쉬운 방법 중 하나가 Cloudflare Tunnel 앱 커넥터인 cloudflared를 통하는 것이었습니다. 대부분의 경우 이렇게 하면 잘 작동하지만, 시간이 지나면서 고객들이 cloudflared의 기본 아키텍처 기반으로 지원할 수 없는 롱테일 사용 사례를 찾아내기 시작했습니다. 여기에는 고객이 VOIP 전화를 사용하는 경우, 사용자의 소프트폰에 발신 연결을 설정하기 위해 SIP 서버가 필요하거나 CI/CD 파이프라인의 각 단계마다 관련 이해관계자에게 알림을 보내는 CI/CD 서버가 필요한 상황이 포함됩니다. 이 블로그 게시물 뒷부분에서 이러한 사용 사례를 자세히 살펴봅니다.

_clouflared_는 OSI 모델의 계층 4에서 프록시 되므로 해당 디자인은 원본 서비스에 대한 요청을 프록시 하도록 특별히 최적화되었으며 원본 서비스의 요청을 처리하기 위한 활성 리스너로 설계되지 않았습니다. 이러한 설계 상충 관계는 cloudflared가 앱 서버에 프록시 하는 모든 요청을 NAT에서 소싱해야 함을 의미합니다. 이 설정은 고객이 원래 서비스 앞에 cloudflared를 배포하기 위해 라우팅 테이블을 업데이트하지 않아도 되는 시나리오에는 편리합니다. 하지만 이는 또한 고객이 요청을 보내는 클라이언트의 실제 소스 IP를 볼 수 없음을 의미합니다. 이는 네트워크 방화벽이 모든 네트워크 트래픽을 기록하는 시나리오에서 중요합니다. 모든 요청의 소스 IP가 cloudflared의 IP 주소가 되어 고객이 실제 클라이언트 소스에 대한 가시성을 잃게 되기 때문입니다.

이 문제를 해결하기 위해 우리는 새 커넥터를 만들어 처음부터 시작하거나 cloudflared 또는 Warp에서 기존 커넥터에서 차용하는 두 가지 잠재적 솔루션을 확인했습니다.

다음 표에서는 두 가지 접근 방식의 장단점을 간략하게 설명합니다.

기능

Features	Build in cloudflared	Borrow from WARP
Bidirectional traffic flows	As described in the earlier section, limitations of Layer 4 proxying.	This does proxying at  Layer 3, because of which it can act as default gateway for that subnet, enabling it to support traffic flows from both directions.
User experience	For Cloudflare One customers, they have to work with two distinct products (cloudflared and WARP) to connect their services and users.	For Cloudflare One customers, they just have to get familiar with a single product to connect their users as well as their networks.
Site-to-site connectivity between branches, data centers (on-premise and cloud) and headquarters.	Not recommended	For sites where running  agents on each device is not feasible, this could easily connect the sites to users running WARP clients in other sites/branches/data centers. This would work seamlessly where the underlying tunnels are all the same.
Visibility into true source IP	It does source NATting.	Since it acts as the default gateway, it preserves the true source IP address for any traffic flow.
High availability	Inherently reliable by design and supports replicas for failover scenarios.	Reliability specifications are very different for a default gateway use case vs endpoint device agent. Hence, there is opportunity to innovate here.

Cloudflared에서 빌드

Warp로부터 차용 

양방향 트래픽 흐름

이전 섹션에서 설명한 것처럼 계층 4 프록시 설정의 한계입니다.

이는 계층 3에서 프록시를 설정하므로 

해당 서브넷의 기본 게이트웨이 역할을 하여 양방향에서 트래픽 흐름을 지원할 수 있습니다.

사용자 경험

Cloudflare One 고객의 경우 두 가지 고유한 제품(cloudflared 및 Warp)을 사용하여 서비스와 사용자를 연결 해야 합니다.

Cloudflare One 고객은 하나의 제품에 익숙해지기만 하면 사용자와 네트워크를 연결할 수 있습니다.

지사, 데이터 센터(온프레미스 및 클라우드), 본사 간의 사이트 간 연결성.

권장하지 않음

각 장치에서 에이전트를 실행하는 것이 불가능한 사이트의 경우, 이렇게 하면 다른 사이트/지사/데이터 센터에서 Warp 클라이언트를 실행하고 있는 사용자와 사이트를 쉽게 연결할 수 있습니다. 이는 기본 터널이 모두 동일한 경우 원활하게 작동합니다.

실제 소스 IP에 대한 가시성

NAT를 소싱합니다.

이는 기본 게이트웨이 역할을 하므로 모든 트래픽 흐름에 대해 실제 소스 IP 주소를 유지합니다.

높은 가용성

본질적으로 안정적으로 설계되었으며 장애 조치 시나리오를 위한 복제본을 지원합니다.

기본 게이트웨이 사용 사례와 엔드포인트 장치 에이전트의 안정성 사양은 아주 다릅니다. 따라서, 여기에서 혁신할 기회를 얻을 수 있습니다. 

오늘부터 WARP Connector 의 도입으로 새로운 가능성이 열렸습니다. 서버 시작(SIP/VOIP) 흐름, 사이트 간 연결, 지점, 본사 및 클라우드 플랫폼 연결, WARP 대 WARP를 통한 메시형 네트워킹도 가능합니다. 내부적으로 이 새로운 커넥터는 Cloudflare를 통한 트래픽 온램프(on-ramp)/오프 램프(off-ramp)에 대해 네트워크 내의 모든 서브넷에 대한 가상 라우터 역할을 할 수 있는 warp 클라이언트의 확장입니다.

WARP를 구축함으로써 저희는 호스트에 가상 네트워크 인터페이스를 생성하여 IP 트래픽 라우팅을 위해 물리적 인터페이스(NIC)를 논리적으로 세분화하는 설계를 활용할 수 있었습니다. 이를 통해 호스트와 Cloudflare 에지 사이에 유지되는 WireGuard/MASQUE 터널을 통해 양방향 트래픽을 보낼 수 있습니다. 이 아키텍처 덕분에 고객은 클라이언트의 실제 소스 IP에 대한 가시성을 추가로 얻을 수 있습니다.

WARP Connector는 추가로 라우팅을 변경하지 않고 기본 게이트웨이에 쉽게 배포할 수 있습니다. 아니면 WARP Connector를 통해 라우팅해야 하는 특정 CIDR에 정적 경로를 구성하고 기본 게이트웨이 또는 해당 서브넷의 모든 호스트에 정적 경로를 구성할 수 있습니다.

여기에서는 새로운 커넥터를 배포해야 하는 몇 가지 주요 이유를 살펴보겠지만, 이 솔루션은 Microsoft의 System Center Configuration Manager(SCCM), Active Directory 서버 업데이트, VOIP 및 SIP 트래픽, 복잡한 CI/CD 파이프라인 상호 작용이 있는 개발자 워크플로우 등 수많은 서비스를 지원할 수 있다는 점을 기억하세요. 또한, 이 커넥터는 cloudflared 및 Magic WAN과 함께 실행하거나 Cloudflare 전역 네트워크에 대한 독립형 원격 액세스 및 사이트 간 커넥터로 사용할 수 있다는 점도 유의해야 합니다.

사용자가 VOIP 소프트웨어 서비스를 통해 음성 또는 영상 통화를 설정하는 경우, 일반적으로 사설 네트워크 내의 SIP 서버가 최종 사용자의 마지막으로 알려진 IP 주소를 사용하여 연결을 중개합니다. 그러나 트래픽이 경로를 따라 프록시 설정된 경우에는 참여자가 음성 또는 데이터 신호를 부분적으로만 수신하는 경우가 많습니다. 이제 고객은 WARP Connector를 통해 이러한 서비스에 보안 액세스에 대한 세분화된 정책을 적용하여 Zero Trust 프레임워크내에서 VOIP 인프라를 강화할 수 있습니다.

조직의 DevOps 생태계는 일반적으로 여러 부분으로 구축되지만, Jenkins, Teamcity 등의 CI/CD 서버는 모든 개발 활동의 진원지입니다. 따라서 해당 CI/CD 서버를 보호하는 것이 중요합니다. WARP Connector 및 Warp Client를 사용하면 조직에서 전체 CI/CD 파이프라인을 보호하고 쉽게 간소화할 수도 있습니다.

Kubernetes 앱의 일반적인 CI/CD 파이프라인을 살펴보겠습니다. 환경은 위 다이어그램과 같이 설정되어 있으며, 개발자 및 QA 노트북의 WARP 클라이언트와 서로 다른 네트워크에 있는 CI/CD 서버와 스테이징 서버를 안전하게 연결하는 WARP Connector가 있습니다.

1. 일반적으로 CI/CD 파이프라인은 개발자가 코드 변경을 커밋하여 CI/CD 서버에서 웹후크를 호출할 때 트리거됩니다.

2. 이미지가 빌드되면 코드를 배포할 시간이며, 이는 일반적으로 테스트, 스테이징, 프로덕션의 단계로 수행됩니다.

3. 테스트/스테이징 환경에서 이미지가 준비되면 개발자와 QA 엔지니어에게 알림이 전송됩니다.

4. QA 엔지니어는 CI/CD 서버로부터 웹후크를 통해 알림을 받아 모니터링 및 문제 해결 워크플로우를 시작할 수 있습니다.

고객은 WARP Connector를 사용하여 생태계를 비공개로 유지하고 공개적으로 노출되지 않도록 하여 자체 개발자를 DevOps 생태계의 도구에 쉽게 연결할 수 있습니다. DevOps 생태계가 Cloudflare에 안전하게 연결되면 세분화된 보안 정책을 쉽게 적용하여 CI/CD 파이프라인에 대한 액세스를 보호할 수 있습니다.

Microsoft AD 서버 또는 웹 앱이 아닌 서버를 실행하는 조직에서는 감사 또는 정책 적용을 위해 실제 소스 IP 주소를 식별해야 하는 경우가 많습니다. 이러한 요구 사항이 있는 경우 WARP Connector는 이를 단순화하여 NAT 경계를 추가하지 않고 솔루션을 제공합니다. 이는 비정상 소스 IP 주소를 레이트 리미트 설정하거나 경계 내의 ACL 기반 정책에 대해 또는 최종 사용자로부터 추가 진단을 수집하는 데 유용할 수 있습니다.

이번 출시의 일환으로 저희는 다양한 네트워크 온램프(on-ramp)/오프램프(off-ramp) 옵션이 더 잘 보이도록 Cloudflare One 대시보드를 몇 가지 변경하려고 합니다. 오늘부로 대시보드에 새로운 '네트워크' 탭이 나타납니다. 이곳이 Cloudflare Tunnel UI의 새로운 홈이 됩니다.

또한 '터널' 옆에 새로운 '경로' 탭을 도입합니다. 이 페이지에는 고객의 가상 네트워크, Cloudflare Tunnel, 이와 연결된 경로에 대한 조직적인 보기가 표시됩니다. 이 새로운 페이지는 다음과 같은 네트워크 구성과 관련된 고객의 질문에 대한 답변을 제공합니다. "내 호스트 192.168.1.2로 가는 경로가 있는 Cloudflare Tunnel은 무엇인가요?" 또는 "CIDR 192.168.2.1/28의 경로가 존재하는 경우 어떻게 액세스할 수 있나요?" 또는 "내 환경에서 겹치는 CIDR은 무엇이며 어떤 VNET에 속해 있나요?" 등입니다. 이는 연결 문제를 해결하기 위해 Cloudflare dashboard를 사용하는 매우 복잡한 기업 네트워크를 보유한 고객에게 매우 유용합니다.

WARP Connector 여정을 시작하는 방법은 간단합니다. 현재 Linux 호스트에 배포할 수 있으며, 사용자는 'Tunnel 생성'을 선택하고 cloudflared 또는 Warp를 대시보드에서 바로 배포하여 선택할 수 있습니다. 개발자 문서를 따라 간단한 몇 단계만 진행하면 시작할 수 있습니다. 가까운 미래에 WARP Connector를 배포할 수 있는 더 많은 플랫폼에 대한 지원을 추가할 예정입니다.

귀중한 피드백을 주신 Cloudflare의 비공개 베타 고객 모두에게 감사의 말씀을 전합니다. 앞으로 계획을 말씀드리자면, 다음 분기에 당면한 목표는 배포를 간소화하고, cloudflared의 배포를 모방하며, 이중화 및 장애 조치 메커니즘을 통해 고가용성을 강화하는 것입니다.

Cloudflare One 플랫폼을 혁신하고 개선하는 여정이 계속되는 동안 업데이트되는 내용을 계속 지켜봐 주세요. 고객 여러분이 WARP Connector를 활용하여 연결과 보안 환경을 변화시켜 나가는 모습을 보게 되어 정말 기쁩니다.