본문으로 건너뛰기
J
피드

Qanah — WireGuard 설정 그대로 쓰면서 WebRTC로 NAT 뚫는 P2P VPN

devops 약 4분
tags
#vpn#webrtc#wireguard#p2p#nat-traversal
vote
0
댓글
북마크
원문 보기

WireGuard 설정 파일을 그대로 사용하면서 UDP 대신 WebRTC 데이터 채널로 IP 패킷을 터널링하는 P2P VPN. CGNAT 뒤에서도 동작하고, WireGuard가 차단된 네트워크에서도 사용 가능.

  • 1

    WireGuard 설정 파일 호환, UDP 대신 WebRTC 데이터 채널 사용

  • 2

    ICE/STUN으로 NAT 통과 — 공인 IP, 포트 포워딩 불필요

  • 3

    메시 네트워킹 + 1홉 릴레이 지원

  • 4

    ChaCha20-Poly1305 + X25519 암호화, PresharedKey로 포스트 퀀텀 저항

  • Qanah(قَناة, 아랍어로 "터널")은 WireGuard 설정 파일을 그대로 쓰면서 WebRTC 데이터 채널 위에 VPN 터널을 만드는 P2P VPN임. 전통적인 WireGuard UDP 전송 대신 TUN 디바이스를 만들어서 raw IP 패킷을 WebRTC로 터널링하는 방식

  • 이게 왜 의미가 있냐면:

    • CGNAT 뒤에 있어도 됨 — ICE/STUN으로 NAT 통과하니까 공인 IP도, 포트 포워딩도, 업스트림 네트워크 제어도 필요 없음
    • WireGuard/UDP가 차단된 네트워크에서도 동작 — ISP나 국가 방화벽이 WireGuard 프로토콜이나 아웃바운드 UDP를 막아도 WebRTC/ICE 경유로 표준 포트를 통해 빠져나감
    • 메시 네트워킹 지원 — 여러 피어가 동시 연결 가능하고, 직접 연결 안 되는 피어로의 트래픽은 다른 연결된 피어를 경유해 1홉 릴레이
sequenceDiagram
    participant 피어A as 피어 A (CGNAT 뒤)
    participant MQTT as MQTT 시그널링 서버
    participant STUN as STUN 서버
    participant 피어B as 피어 B (CGNAT 뒤)
    피어A->>MQTT: SDP offer 전송
    MQTT->>피어B: SDP offer 전달
    피어B->>MQTT: SDP answer 전송
    MQTT->>피어A: SDP answer 전달
    피어A->>STUN: ICE candidate 수집
    피어B->>STUN: ICE candidate 수집
    피어A->>피어B: WebRTC 데이터 채널 (ChaCha20-Poly1305 암호화)
    피어B->>피어A: 양방향 IP 패킷 터널링

  • 암호화는 X25519 키 교환 + ChaCha20-Poly1305. WireGuard 설정의 PrivateKey/PublicKey로 공유 비밀을 유도하고, PresharedKey가 있으면 포스트 퀀텀 저항을 위해 혼합함. 방향별로 독립된 키를 사용

  • 시그널링은 기본적으로 MQTT 브로커(broker.emqx.io:1883)로 자동 교환하지만, offer/answer 서브커맨드로 수동 복붙 방식도 가능. 일회성 세션(페어 프로그래밍, 서포트 접근, 데모)에 유용함

  • Rust로 작성됐고, Linux에서만 동작(TUN 디바이스 필요), root/sudo 권한 필요. 설정 파일명이 TUN 인터페이스 이름이 되는 건 wg-quick 컨벤션과 동일 (wg0.conf → wg0)

💡팁

> --no-relay 플래그로 릴레이를 끄면 직접 피어 라우트만 사용하고 직접 연결 없는 패킷은 드롭됨. 보안이 중요한 환경에서 유용함

WireGuard의 설정 편의성과 WebRTC의 NAT 통과 능력을 결합한 영리한 접근. CGNAT이나 방화벽 뒤에서 VPN이 막히는 상황에 실용적인 해결책

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

devops

디지털 스택을 유럽으로 옮겨보니, 생각보다 꽤 실전적이었다

한 개발자가 분석, 메일, 비밀번호 관리, 컴퓨트, 오브젝트 스토리지, 백업, 이메일, 에러 추적, AI API까지 유럽 중심 스택으로 옮긴 경험을 정리한 글이다. 핵심은 반미 감정이 아니라 데이터가 어디에 있고, 누가 접근할 수 있고, 정치나 기업 정책 변화에 얼마나 휘둘리는지를 의식하자는 얘기다.

devops

개인용 컴퓨터 다음은 개인용 클러스터라는 주장

이 글은 AI 시대에 개인 한 명이 쓰는 컴퓨팅 자원이 점점 ‘클러스터 한 덩어리’ 수준으로 커질 거라고 주장한다. PC가 직장, 취미 개발자, 게임 문화로 퍼졌듯이 개인용 클러스터도 업무용 AI, 오픈소스 실험, 게임 같은 흐름을 타고 대중화될 수 있다는 시나리오다.

devops

AI 에이전트 부하에 흔들린 GitHub, 왜 다른 서비스보다 더 아팠나

GitHub가 최근 몇 달 동안 가용성 저하, 검색 장애, GitHub Actions 문제, 심지어 squash merge에서 커밋이 빠지는 데이터 무결성 사고까지 겪었다. GitHub CTO는 AI 에이전트발 부하 증가를 원인으로 들었지만, 실제로는 2년간 약 3.5배 증가한 부하와 Azure 이전, 오래된 시스템, 조직적 지연이 겹친 문제에 가깝다. 개발자 입장에선 GitHub가 ‘없으면 안 되는 도구’에서 ‘업무를 막는 병목’으로 보이기 시작했다는 게 핵심이다.

devops

한국 클라우드 시장, 이제 GPU랑 데이터센터 싸움으로 넘어감

국내 클라우드 서비스 제공사들이 AI 전환 수요를 잡기 위해 GPUaaS, 데이터센터, 공공 클라우드 사업에 공격적으로 투자하고 있어. 네이버클라우드, KT클라우드, NHN클라우드 모두 2026년 1분기 실적에서 AI 인프라를 핵심 성장축으로 내세웠고, 정부의 2조805억원 규모 GPU 구축 사업이 판을 더 키우는 중이야.

devops

칩값 뛰니 K게임의 콘솔·피시 전환 해법으로 다시 뜨는 클라우드 게임

국내 게임사들이 모바일 중심에서 콘솔·피시로 넘어가려는 타이밍에 고성능 지피유와 콘솔 가격 상승이 발목을 잡고 있다. 이용자 입장에서는 300만원대 게이밍 피시, 오른 콘솔 가격, 스팀 가격 기준 개편까지 겹치면서 고사양 게임 접근성이 떨어지는 상황이다. 업계는 원격 서버에서 게임을 실행해 스트리밍하는 클라우드 게임을 다시 현실적인 대안으로 보고 있다.