# JIT WireGuard 기술

> Clean Markdown view of GeekNews topic #13793. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=13793](https://news.hada.io/topic?id=13793)
- GeekNews Markdown: [https://news.hada.io/topic/13793.md](https://news.hada.io/topic/13793.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-03-14T09:51:40+09:00
- Updated: 2024-03-14T09:51:40+09:00
- Original source: [fly.io](https://fly.io/blog/jit-wireguard-peers/)
- Points: 1
- Comments: 1

## Topic Body

### Fly.io의 WireGuard 개선 사항

- Fly.io는 컨테이너를 VM으로 변환하여 전 세계적으로 하드웨어에서 Firecracker의 힘을 이용해 실행함.
- WireGuard를 많이 사용하며, 이제 고객 API의 일부가 됨.
- `flyctl` CLI를 실행할 때마다 TCP/IP 스택을 생성하고, 고유한 IPv6 주소를 사용하여 Fly Machines과 직접 통신함.
- 이 접근 방식의 장단점이 있으며, 몇 가지 개선 사항이 있음.

### 이전 상황

- 전 세계에 있는 "게이트웨이" 서버들이 WireGuard 연결을 수락하고 적절한 사설 네트워크에 연결하는 역할을 함.
- `flyctl`을 실행할 때마다 백그라운드 에이전트 프로세스를 생성하거나 연결함.
- 에이전트는 GraphQL API에서 새로운 WireGuard 피어 설정을 생성함.
- API는 NATS 메시징 시스템을 통해 적절한 게이트웨이에 피어 설정을 전송함.
- 게이트웨이에서 `wggwd` 서비스가 설정을 받아 SQLite 데이터베이스에 저장하고 커널에 추가함.
- API가 GraphQL 요청에 응답하여 설정을 전달하고, `flyctl`이 WireGuard 피어에 연결함.
- NATS는 빠르지만 배달을 보장하지 않으며, 게이트웨이에 남아 있는 오래된 피어들을 정리하지 않음.

### 더 나은 방법

- WireGuard 피어를 저장하는 것은 복잡한 데이터베이스가 필요하지 않음.
- 게이트웨이가 API에서 필요할 때마다 설정을 가져오도록 변경함.
- 클라이언트가 연결을 원할 때만 커널에 피어를 추가하고, 필요 없을 때는 제거할 수 있음.

### JIT WireGuard 피어 가능

- Linux 커널의 WireGuard 설정 인터페이스는 Netlink를 사용함.
- WireGuard 연결 요청 패킷을 BPF 필터와 패킷 소켓으로 식별하고 가로챌 수 있음.
- WireGuard는 "클라이언트"와 "서버" 개념이 없으며, 점대점 프로토콜임.
- `flyctl`이 게이트웨이에 UDP 패킷을 보내면, 이는 `handshake initiation`임.
- BPF 필터를 사용하여 들어오는 연결을 잡을 수 있음.
- Noise 프로토콜 프레임워크를 기반으로 하여, 요청을 식별하기 위해 암호화를 해제해야 함.
- 이벤트 피드를 생성하여 게이트웨이에 연결을 시도하는 모든 사용자의 공개 키를 얻을 수 있음.
- 새로운 피어를 볼 때마다 내부 HTTP API 요청을 통해 해당 피어 정보를 가져오고 설치함.

### 앱을 분 단위로 런칭

- Fly.io에서 앱을 빠르게 배포하고 자체 JIT WireGuard 피어를 얻을 수 있음.

### 그래프 살펴보기

- 몇 주 동안 이 시스템을 운영하며, 게이트웨이에 남아 있는 오래된 WireGuard 피어 수를 현저히 줄임.
- 게이트웨이가 더 적은 상태를 유지하고 피어 설정이 더 빨라짐.
- Grafana 차트를 통해 전환 당일의 성공적인 결과를 공유함.

### GN⁺의 의견

- Fly.io의 WireGuard 개선은 네트워크 성능과 안정성을 크게 향상시키는 좋은 예시임.
- 이러한 접근 방식은 특히 클라우드 기반 서비스에서 네트워크 트래픽 관리와 보안을 강화하는 데 도움이 될 수 있음.
- 비슷한 기능을 제공하는 다른 프로젝트로는 Tailscale이나 ZeroTier가 있으며, 이들도 개인 및 기업 사용자에게 VPN 대안을 제공함.
- WireGuard를 도입할 때는 네트워크 구성, 보안 정책, 호환성 등을 고려해야 함.
- 이 기술을 선택함으로써 얻는 이점은 빠른 성능과 간단한 구성이지만, 기존 인프라와의 통합이나 관리 측면에서 도전이 될 수 있음.

## Comments



### Comment 23699

- Author: neo
- Created: 2024-03-14T09:51:40+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=39688545) 
- > 리눅스 커널의 WireGuard는 요청 시 피어를 설치하는 기능이 없어 설계 구축에 문제가 발생한다고 합니다.
  - 리눅스 커널의 WireGuard가 요청에 따라 피어를 설치하는 기능 부재로 설계에 어려움이 있음.
  - 런타임에 피어를 추가할 수 있지만, 인터페이스에 추가하기 전에 피어를 인증하여 불필요한 항목을 방지하려는 것으로 보임.
  - eBPF 필터를 사용하여 인증된 상대방과의 암호키 라우팅 기반 연결을 직접 관리하고, 검증이 완료되면 피어를 인터페이스에 추가하고 타임아웃 후 제거함.

- > HTTP 요청이 메시지 큐를 통한 라우팅보다 더 신뢰성이 있다는 데는 동의하지만, NATS로 인해 손실된 메시지가 서비스에 큰 영향을 미쳤다는 것에 놀랐습니다.
  - 직접 HTTP 요청이 메시지 큐보다 신뢰성이 높다는 의견에 동의하지만, NATS에서 메시지 손실이 서비스에 상당한 영향을 미쳤다는 점에 대해 의아함.
  - 메시지 손실 시 NATS가 재전송을 시도할 것으로 예상되지만, 눈에 띄는 신뢰성 문제가 발생한 이유에 대해 궁금증을 표함.

- > 최근 실험적인 프로젝트를 홍보하고 싶습니다. 사용자 공간 WireGuard 피어로 작동하는 Go 앱을 구축하는 데 관심이 있다면 확인해 보세요.
  - 사용자 공간 WireGuard 피어로 작동하는 Go 앱을 구축하는 데 관심 있는 사람들을 위해 자신의 프로젝트를 소개함.
  - wireguard-go의 우수한 작업을 기반으로 하되, 라이브러리 사용에 더 적합하도록 단순화하고자 함.
  - 서비스 메시 구축에 관심이 있으며, 다양한 언어 지원이 어려울 수 있지만 소켓 API를 구현할 수 있을 것으로 생각함.
  - WireGuard의 암호화에 대한 하드웨어 가속이 아직 보이지 않아 mTLS와 경쟁하기 어려울 수 있음을 언급함.
  - 고속/보안 네트워킹 분야에서 프리랜서로 활동하고 있으며, 관심 있는 사람은 연락 바람(이메일 프로필에 있음).

- > WireGuard를 WebSockets 위에 터널링하는 것이 기본 설정이라는 것이 흥미롭습니다. 성능에는 좋지 않지만 flyctl이 사용되는 DevOps 작업에는 적합할 것입니다.
  - WireGuard를 WebSockets를 통해 터널링하는 것이 기본 설정이라는 사실에 주목함.
  - 성능에는 최적이 아니지만, flyctl이 사용되는 DevOps 작업에는 문제가 없을 것으로 예상함.
  - QUIC/HTTP3의 미래에 대해 궁금해하며, 네트워크 운영자들이 UDP를 443 포트에서 차단하는 대신 제대로 처리할 가능성에 대해 의문을 제기함.

- > 우리는 발신자로서 피어를 설치할 수 있으며, flyctl이 응답자입니다. 리눅스 커널은 flyctl로 WireGuard 연결을 시작합니다. 이 방법은 작동하며, 프로토콜은 서버와 클라이언트가 누구인지 크게 신경 쓰지 않습니다. 새로운 연결이 가능한 한 빨리 설치됩니다.
  - 발신자로서 피어를 설치하고 flyctl이 응답자로서 리눅스 커널이 WireGuard 연결을 시작하는 방식에 대해 설명함.
  - 프로토콜이 서버와 클라이언트의 역할에 크게 구애받지 않으며, 새로운 연결이 매우 빠르게 이루어질 수 있음을 언급함.

- > 내 스타트업은 거의 1년 동안 Fly를 사용했습니다. 코드를 배포된 코드로 1분 이내에 전환하는 핵심 기능은 아름답습니다. 새 노드를 몇 초 만에 스핀업/다운할 수 있습니다.
  - 스타트업이 Fly를 거의 1년간 사용한 경험을 공유함.
  - 코드를 빠르게 배포할 수 있는 기능에 대해 긍정적으로 평가하지만, 회사가 다소 미성숙하다고 느낌.
  - API 서버가 Fly에서 48시간 동안 접근 불가능했던 경험과, "db" 제품의 일관성 없는 연결 끊김 문제를 언급함.
  - Fly의 API 접근이 자주 다운되어 새로운 서비스 수정을 배포하는 데 문제가 있었음을 지적함.
  - 배포 경험은 그리워하지만, GCP의 Cloud Run을 사용하는 것이 더 만족스러움을 표현함.

- > “flyctl을 실행할 때마다, 우리의 사랑스러운, 방대한 CLI는 공중에서 TCP/IP 스택을 만들어내고, 고유한 IPv6 주소를 가지고 직접 Fly Machines과 통신합니다.”
  - flyctl 실행 시 TCP/IP 스택을 즉석에서 생성하고 고유한 IPv6 주소를 통해 Fly Machines과 직접 통신한다는 설명에 대한 궁금증을 표함.

- > 초기 핸드셰이크 패킷이 네트워크 스택으로 재전송되는 것을 막는 것은 무엇인가요? 그렇게 하면 패킷 손실이 없을 것 같습니다. 또한 eBPF 필터에서 "udp[8] = 1"을 확인하는 목적은 무엇인가요?
  - 초기 핸드셰이크 패킷이 네트워크 스택으로 재전송되는 것을 방지하는 메커니즘과 eBPF 필터에서 특정 UDP 패킷 값을 확인하는 이유에 대한 질문을 제기함.

- > 임의의 도커화된 애플리케이션을 Fly.io에 배포하려면 어떻게 해야 하나요? 제 돈을 가져가세요
  - 도커화된 애플리케이션을 Fly.io에 배포하는 방법에 대한 관심과 의지를 표현함.

- > 다른 모든 사람들을 위해, Netmaker를 뻔뻔스럽게 홍보하겠습니다.
  - Netmaker를 사용한 만족스러운 경험을 공유하며, AWS VPC에 대한 개인적인 접근 필요성을 언급하고, Netmaker가 더 널리 채택되기를 희망함.