Lobsters

High performance policy routed IPsec mesh SD-WAN

고성능 정책 라우팅 IPsec 메시 SD-WAN

ranet3는 사용자 공간 ESP와 IKEv2, Babel, SRv6를 조합한 메시 SD-WAN 프로젝트입니다. 두 대의 10GbE 서버에서 수행한 벤치마크에서 단일 방향 처리량은 사용자 공간 WireGuard와 커널 WireGuard, IPsec보다 높았지만 p99 지연 시간과 CPU 비용은 비교 대상에 따라 달랐습니다.

에디터 노트

제시된 수치는 사용자 공간 데이터 경로가 이 장비와 설정에서 높은 처리량을 낼 수 있다는 점을 보여줍니다. 다만 ranet3의 p99 지연 시간은 커널 구현보다 높았고 CPU 비용도 비교 대상과 부하에 따라 달라졌습니다. 따라서 처리량만으로 전체 성능 우위를 판단하기 어렵습니다. 결과는 두 대의 특정 서버에서 TCP를 측정한 값이며 다른 하드웨어나 실제 메시 구성에서도 같은 차이가 난다는 자료는 없습니다. Lobsters 댓글은 성능 수치보다 실제 운용 모델에 질문을 던집니다. 공인 주소를 각 기기에 설정해 사용한다는 경험담은 배포 사례 하나를 보여주지만 NAT 펀칭, 주소 배정, 종단 간 암호화, 해외 접속 시 경로 선택의 동작을 답해주지는 않습니다. 이런 항목은 메시 SD-WAN을 기존 메시 VPN과 비교할 때 필요한 조건이며, 본문은 프로토콜과 성능 측정을 설명하는 데 집중합니다.

AI 요약

ranet3는 표준 네트워크 프로토콜을 조합해 메시 SD-WAN을 구현하는 프로젝트입니다. 데이터 경로는 UDP 위에서 동작하는 사용자 공간 ESP(RFC 4303, RFC 3948)이며, IKEv2(RFC 7296)로 연결을 설정하고 ML-KEM을 결합한 하이브리드 키 교환(RFC 9370)을 지원합니다. 경로 계산에는 Babel(RFC 8966)을 쓰며 RTT 측정(RFC 9616)과 소스별 경로(RFC 9079)를 지원합니다. 소스·목적지 프리픽스 정책에 따라 트래픽을 지정한 중계 지점과 출구로 보내는 기능은 SRv6(RFC 8986)로 구현합니다.

표준 프로토콜과 경로 정책

프로젝트는 strongSwan과 IKEv2·ESP 세션을, BIRD와 Babel 경로를, Linux의 seg6local 기능과 SRv6 헤더 처리를 상호 운용 대상으로 제시합니다. Babel은 각 링크의 RTT를 계속 측정하고 패킷 손실과 장애를 경로 선택에 반영합니다. 직접 연결보다 중계 경로가 빠르면 중계하고, 직접 연결이 더 빨라지면 경로를 되돌립니다.

SRv6 정책은 소스와 목적지 프리픽스를 기준으로 적용하며, 사용자가 지정한 순서대로 경유지를 거칠 수 있습니다. 예를 들어 A에서 B, C, 다시 B를 거쳐 D로 보내고 D를 출구로 삼을 수 있습니다. 이 기능은 사용자 공간에서 동작하므로 SRv6를 커널에서 지원하지 않는 macOS에서도 사용할 수 있다고 설명합니다. Tailscale, NetBird, ZeroTier, Nebula 같은 메시 VPN 에이전트와 같은 호스트에서 함께 실행하는 방식도 제시합니다.

벤치마크 결과와 조건

비교 대상은 사용자 공간 wireguard-go, 커널 WireGuard, 커널 IPsec입니다. ranet3는 AES-256-GCM을 쓰고 나머지 WireGuard 구현은 ChaCha20-Poly1305를 씁니다. 측정 장비는 Intel Xeon Gold 6130 16코어 프로세서와 Intel X710 네트워크 카드가 장착된 Dell PowerEdge C6420 서버 두 대입니다. 두 서버는 같은 스위치에 연결했고 각 방향 대역폭은 10Gbps입니다. Debian 13, Linux 6.12.111에서 내부 MTU 1400인 TCP 트래픽을 1개 또는 8개 스트림으로 보냈습니다. 각 조건을 10초씩 세 번 측정한 중앙값을 사용했고, 처리량과 지연 시간은 포화 상태에서, CPU 비용은 양방향 각 3Gbps에서 측정했습니다.

1개 스트림의 단방향 처리량은 ranet3 8.39Gbps, wireguard-go 6.77Gbps, 커널 WireGuard 5.35Gbps, 커널 IPsec 4.67Gbps였습니다. 양방향 동시 전송에서는 각각 14.87Gbps, 10.78Gbps, 7.46Gbps, 4.67Gbps였습니다. 8개 스트림 양방향 처리량은 ranet3 15.79Gbps, wireguard-go 10.33Gbps, 커널 WireGuard 7.41Gbps, 커널 IPsec 4.10Gbps였습니다. 벤치마크는 ranet3의 처리량이 wireguard-go보다 1.2~1.5배, 커널 WireGuard보다 1.6~2.1배, 커널 IPsec보다 1.8~3.9배 높았다고 집계합니다. 반면 p99 지연 시간은 wireguard-go와 비교해 혼합된 결과였고, 커널 WireGuard보다 1.9~2.4배, 커널 IPsec보다 1.6~2.0배 나빴습니다. CPU 비용 역시 비교 대상에 따라 유리하거나 불리했습니다.

Lobsters 반응

  • @tuxes — 저는 메시 VPN 선택지에 꽤 불만이 많아서 새 메시를 도입하기보다는 "메시는 쓰지 않고 IPv6와 워크로드 mTLS만 쓰는" 쪽에 더 가깝습니다. 그래도 더 알아보고 싶습니다. 일반적인 메시 VPN과 SD-WAN 도구는 자체 에이전트를 실행하는 노드만 받아들이지만 ranet3는 같은 호스트에서 그런 도구와 나란히 실행된다고 하셨습니다. 그래서 여러 메시 VPN의 대안 가운데 하나로 이해하면 될 것 같습니다. 이 분야를 잘 몰라 질문이 맞지 않을 수도 있습니다. 일반적인 메시 VPN에서 직접 연결보다 다른 노드를 거치는 편이 빨라지는 경우는 언제인가요? 소스와 목적지 프리픽스 정책으로 지정한 경유지를 통과시키고 출구를 고르는 기능은 어떤 상황에 쓰나요? 지정한 출구는 Tailscale exit node와 비슷한가요? 일반 메시 VPN과 비교했을 때 어떤 제약이 있나요? NAT 펀칭은 하지 않고, MacBook처럼 직접 연결할 수 없는 노드가 연결 가능한 노드로 접속한 뒤 가장 나은 경로를 찾는 구조인가요? 여기서 가장 나은 경로는 정책에 따르거나 RTT가 가장 낮은 경로인가요? 종단 간 암호화를 지원하나요? 노드 A에서 노드 B로 가는 트래픽이 경유지 W를 통과하면 W는 원래 패킷을 보나요, 암호화된 패킷을 보나요? 주소 지정은 어떻게 하나요? 일반 메시 VPN은 노드마다 평면 네트워크 주소를 줍니다. 제가 이해한 바로는 ranet은 사용자가 주소를 가져오는 방식인가요? 두 AS에서 운용한다고 적혀 있으니 사용자가 주소를 가져오는 점이 장점일 것 같습니다. AS가 없고 ISP나 VPS에서 /56을 받는 경우 노트북 주소는 보통 어떻게 배정하나요? 정적 라우팅을 쓰나요? 해외에 있을 때 메시 노드에 접속하면서 집을 경유해 왕복 지연이 늘어나는 상황을 피하려면 어떻게 하나요? 이 경우가 다른 노드를 거치는 편이 더 빠른 상황인가요?
  • @ysun — 참고로 제 모든 기기에서 이미 실행 중이고 MacBook도 포함됩니다. 모든 기기에 라우팅 가능한 공인 IP를 설정했습니다. 특히 동적 IPv4만 제공하는 SFR의 동축 인터넷을 쓰는 Mac에서는 이걸 이용해 라우터 뒤 기기 모두에 안정적인 IPv4·IPv6 주소를 쉽게 줄 수 있습니다. iOS·Android 앱도 곧 나옵니다.
원문 보기 ↗토론 보기 ↗