2025년 4월 22일 화요일

Tailscale 작동 원리 - WireGuard

How Tailscale works 번역 (원문 보기)

아래에서는 Tailscale 시스템을 바닥에서부터 정점까지, 구축한 순서대로(중간에 거쳤던 우회 경로는 생략) 살펴보겠습니다. 이 정보를 통해 직접 Tailscale 대체 솔루션을 구축하실 수도 있지만, Tailscale 노드 소프트웨어는 오픈 소스이고 무료 플랜도 유연하게 제공되니 굳이 그럴 필요는 없습니다.

데이터 플레인(Data Plane): WireGuard®

저희의 기본 계층은 점점 인기를 얻고 있는 뛰어난 오픈 소스 WireGuard 패키지(특히 userspace Go 변형인 wireguard-go)입니다. WireGuard는 컴퓨터, VM 또는 컨테이너(이를 "엔드포인트(endpoint)"라고 하며, 저희는 "노드(node)"라고 부릅니다)와 네트워크 내의 다른 모든 노드 사이에 매우 가벼운 암호화 터널을 생성합니다.

명확히 하자면: 대부분의 경우, VPN 사용자(및 WireGuard 사용자 포함)는 각 클라이언트 장치(예: 노트북)가 중앙 "집중기(concentrator)" 또는 VPN 게이트웨이에 연결되는 "허브 앤 스포크(hub-and-spoke)" 아키텍처를 구축합니다.

허브 앤 스포크 네트워크

그림 1. 전통적인 허브 앤 스포크 VPN

이 방식이 WireGuard 설정에서 가장 쉽습니다. 네트워크 내 각 노드는 직접 연결하려는 다른 노드의 공개 키, 공용 IP 주소, 포트 번호를 알아야 하기 때문입니다. 10개의 노드를 완전 연결하려면 각 노드가 9개의 피어 정보(총 90개의 터널 엔드포인트)를 알아야 하지만, 허브 앤 스포크에서는 하나의 중앙 허브 노드와 9개의 말단 노드(스포크)만 알면 되어 훨씬 간단합니다. 허브 노드는 일반적으로 고정 IP와 방화벽의 개방 포트를 갖추고 있어 다른 모든 노드가 쉽게 찾을 수 있습니다. 그 후 클라이언트-서버 인터넷 프로토콜 방식으로 방화벽 뒤에 있는 노드라도 허브에 연결 요청을 보낼 수 있습니다.

허브 앤 스포크 방식에는 단점도 있습니다. 우선, 현대 기업은 단일 허브를 지정할 물리적 장소가 한 곳이 아닙니다. 여러 오피스, 클라우드 데이터센터 또는 리전, VPC 등이 존재합니다. 전통적인 VPN 구성에서는 한 곳의 VPN 집중기를 설정한 후 위치 간에 IPsec과 같은 보조 터널을 구성합니다. 따라서 원격 사용자는 한 위치의 VPN 집중기에 도착하고, 그곳에서 트래픽이 최종 목적지로 전달됩니다.

이러한 전통적인 설정은 확장하기 어렵습니다. 우선, 원격 사용자가 VPN 집중기에 가깝지 않을 경우 연결 지연(latency)이 높아집니다. 또한, 사용자가 접근하려는 데이터센터가 VPN 집중기와 가까이 있지 않으면 다시 한 번 높은 지연이 발생합니다. 예를 들어 뉴욕의 사용자가 샌프란시스코에 있는 본사 VPN 집중기를 거쳐 뉴욕에 있는 서버에 접속하는 상황을 상상해 보세요.

그림 2(a). 전통적인 VPN 집중기를 통한 비효율적 라우팅

다행히도 WireGuard는 다릅니다. 위에서 언급했듯이 "매우 가벼운" 터널을 생성하므로, 간단히 멀티-허브 구성을 만들 수 있습니다.

그림 2(b). WireGuard 다중점 VPN은 트래픽을 보다 효율적으로 라우팅


단, 각 데이터센터에는 고정 IP, 열린 방화벽 포트, WireGuard 키 세트가 필요합니다. 사용자를 추가할 때마다 새 키를 다섯 대의 서버에 배포해야 하고, 서버를 추가할 때마다 해당 키를 모든 사용자에게 배포해야 합니다. 하지만 허브 하나만 설정하는 것의 5배 작업량일 뿐이니 감당할 만합니다.

메시(Mesh) 네트워크

허브 앤 스포크도 잘 작동하지만, 개별 노드 간 직접 통신은 불가능합니다. 과거에는 컴퓨터가 클라우드를 거치지 않고도 파일을 교환할 수 있었지만, 현대 인터넷 아키텍처는 클라우드 중심의 허브 앤 스포크 디자인으로 우연히 진화했습니다.

아까 언급한 "매우 가벼운" WireGuard 터널 덕분에 모든 노드를 상호 연결하는 메시 네트워크를 구현할 수도 있습니다.

그림 3. Tailscale 점대점 메시 네트워크는 지연을 최소화

이론상 우아하지만, 실제로는 까다롭습니다. 10노드 네트워크라면 90개의 터널 엔드포인트 구성이 필요하고, 키를 회전하거나 사용자를 추가/제거할 때마다 모든 노드를 업데이트해야 합니다. 또한 노드가 서로를 찾아야 하므로, 동적 IP와 방화벽 문제도 해결해야 합니다.

Tailscale은 이 모든 과제를 해결합니다! 이제부터 자세히 살펴보겠습니다.

제어 플레인(Control Plane): 키 교환 및 조정

WireGuard를 연결하고 멀티-허브 구성을 만들었습니다. 이제 메시 네트워크를 구축할 차례입니다. 먼저 방화벽과 동적 IP 문제는 잠시 제쳐두고, 모든 노드가 고정 IP를 갖고 방화벽이 없다고 가정해 봅시다. 모든 WireGuard 암호화 키(보다 안전한 형태의 "인증서")를 어떻게 각 장치에 배포할까요?

이를 위해 Tailscale 노드 소프트웨어는 "조정 서버(coordination server)"(login.tailscale.com)와 통신합니다. 이 서버는 공개 키를 교환하는 일종의 중앙 보관소 역할을 합니다.

그림 4. Tailscale 공개 키와 메타데이터가 중앙 조정 서버를 통해 공유

제어 플레인은 허브 앤 스포크 방식이지만, 여기는 거의 트래픽이 흐르지 않으므로 문제되지 않습니다. 데이터 플레인은 여전히 분산 메시입니다. 다음과 같은 과정이 진행됩니다:

  1. 노드는 자체 개인 키를 비공개로 보관하고 공개 키만 조정 서버에 제출합니다.

  2. 노드는 조정 서버에 현재 위치와 도메인 정보를 함께 업로드합니다.

  3. 노드는 해당 도메인에 속한 다른 노드들의 공개 키와 주소 목록을 다운로드합니다.

  4. 노드는 WireGuard 인스턴스를 적절한 공개 키 세트로 구성합니다.

모든 통신은 종단 간 암호화(end-to-end encrypted)되며, 개인 키는 절대 노드를 벗어나지 않습니다. 이를 통해 제로 트러스트 네트워킹(zero trust networking)이 구현됩니다.

로그인 및 2단계 인증(2FA)

조정 서버는 어떤 공개 키를 어떤 노드에 전송할지 어떻게 알까요? 공개 키 자체는 공개되어도 무해하지만, 조정 서버에 어떤 키를 저장할지는 인증된 사용자 또는 기기에 따라 달라집니다.

각 노드는 공개/개인 키 쌍을 생성하고, 로그인 과정에서 해당 공개 키를 사용자 계정 또는 도메인에 연결합니다. Tailscale은 자체 인증을 처리하지 않고, OAuth2, OIDC(OpenID Connect), SAML 제공자를 통해 인증을 위임합니다. 예를 들어 Gmail, GSuite, Office365 등을 사용합니다.

그림 5. 제어 플레인의 Tailscale 2FA 인증 흐름

이를 통해 별도의 사용자 계정 관리 없이 기존 SSO, 2FA 설정을 그대로 활용할 수 있으며, 도메인은 로그인 즉시 활성화됩니다.

NAT 횡단(NAT Traversal)

실제 환경에서는 모든 노드가 고정 IP를 갖고 방화벽 포트를 개방해 두지 않습니다. 카페, 공항, 비행기 등 다양한 네트워크 환경에서 작동해야 합니다.

그림 6. 별도의 NAT 방화벽 뒤에 있는 두 노드도 연결 가능

Tailscale은 STUN 및 ICE 표준 기반의 고급 기법을 사용하여 방화벽 설정 없이도 양방향 통신을 성립시킵니다.

암호화된 TCP 중계(DERP)

일부 네트워크는 UDP를 완전히 차단하거나 ICE 횡단이 불가능할 정도로 엄격할 수 있습니다. 이를 위해 Tailscale은 DERP(Designated Encrypted Relay for Packets) 서버 네트워크를 제공합니다. 이는 ICE의 TURN 서버와 비슷하지만 HTTPS 스트림과 WireGuard 키를 사용합니다.

그림 7. Tailscale은 각 수신자에 가장 가까운 DERP를 통해 비대칭 경로로 트래픽을 중계

DERP 서버도 트래픽을 해독하지 못하며, 단지 암호화된 패킷을 중계할 뿐입니다.

보너스: ACL 및 보안 정책

VPN은 종종 보안 소프트웨어로 오해받지만, 실상은 연결성(connectivity) 소프트웨어입니다. 네트워크 접근을 늘려줄 뿐, 줄여주지는 않습니다. 허브 앤 스포크 VPN은 방화벽과 결합되어 IP 기반 접근 제어를 수행하지만, 메시 네트워크에서는 중앙 집중식 방화벽이 없습니다.

Tailscale은 ACL(접근 제어 목록)과 보안 정책을 중앙 조정 서버에 저장하고, 각 노드에서 수신 패킷을 검사하여 정책에 맞지 않으면 차단합니다.

그림 8. 중앙 ACL 정책이 각 Tailscale 노드의 수신 패킷 필터에서 적용

또한, 조정 서버는 각 노드에 허용된 공개 키 목록만 제공하여, 허가되지 않은 기기는 아예 연결을 시도할 수 없도록 합니다.

보너스: 감사 로그(Audit Logs)

강력한 컴플라이언스 요구사항이 있는 기업은 감사 로그가 필수입니다. 중앙 집중식 트래픽 허브가 없으면 어떻게 로그를 수집할 수 있을까요?

Tailscale은 각 노드가 내부 네트워크 연결 메타데이터를 실시간으로 중앙 로깅 서비스에 스트리밍하도록 합니다. 이로 인해 로그는 출발지와 목적지 노드 양쪽에 기록되어, 단일 노드 위·변조로는 로그 조작이 어렵습니다.

보너스: 점진적 배포(Incremental Deployment)

Tailscale 메시 네트워크는 기존 인프라를 방해하지 않고도 2분 만에 시작할 수 있습니다. 두 대의 장치에 Tailscale 노드를 설치하고 동일 계정 또는 도메인으로 로그인하면 즉시 보안 연결이 구축됩니다.

그 후 서브넷 라우트를 추가하여 전통적 허브 앤 스포크 VPN을 확장하거나, 더 많은 서버에 Tailscale을 설치하여 완전한 점대점 암호화 네트워크(제로 트러스트 네트워킹)를 구축할 수 있습니다.

이렇게 점진적으로 배포한 후에는 기존 레거시 또는 비암호화 접근 방식을 안전하게 종료할 수 있습니다.

감사합니다.

원문: https://tailscale.com/blog/how-tailscale-works

참고 자료 및 링크:

뉴스 및 트랜드 자료 링크

작성자: 댓글 없음:
레이블: , ,
피드 구독하기: 글 (Atom)