VPN과 Overlay Network — WireGuard와 NetBird

서로 다른 네트워크에 있는 장비가 통신하려면 목적지까지 패킷이 이동할 수 있는 경로가 필요하다.

같은 LAN에 있는 장비라면 같은 네트워크 안에서 비교적 단순하게 통신할 수 있다.

 

하지만 사무실 PC에서 데이터센터의 Private Network에 접근하거나, 서로 다른 지역의 서버를 하나의 내부망처럼 연결하려면 중간의 인터넷이나 다른 네트워크를 거쳐야 한다.

 

이때 사설 IP 주소는 공용 인터넷에서 그대로 Routing되지 않기 때문에 서로 떨어진 네트워크 사이에 별도의 논리적인 통신 경로가 필요할 수 있다.

 

이런 경로를 만드는 방법 중 하나가 VPN(Virtual Private Network)이다.

WireGuard는 암호화된 Tunnel을 구성하는 VPN Protocol이고, NetBird는 WireGuard 기반의 여러 Peer와 Network를 관리할 수 있도록 관리 계층을 제공한다.

 

이번 글에서는 VPN과 Tunnel → WireGuard의 패킷 전달 → Overlay Network → Routing Peer → Masquerade 순서로 전체 흐름을 살펴본다. (참고. →네트워크 기초 — IP, Subnet, CIDR 그리고 Routing)

 

목차

1. VPN과 Tunnel
   - Tunnel과 Encapsulation
2. WireGuard는 패킷을 어떻게 전달하는가
   - Peer와 Key
   - AllowedIPs와 Cryptokey Routing
   - 운영체제 Routing Table과 AllowedIPs의 차이
   - Endpoint는 실제 패킷을 보낼 주소다
   - Endpoint와 WireGuard Interface IP의 차이
3. Underlay와 Overlay Network, 그리고 NetBird
   - Underlay Network와 Overlay Network
   - NetBird가 WireGuard Peer를 관리하는 방법
4. Routing Peer로 Private Network에 접근하기
   - 모든 자원을 직접 Peer로 만들 수 없는 이유
   - Network Resource와 Routing Peer
5. Routing Peer와 Masquerade
   - Masquerade를 사용하는 경우
   - Masquerade를 사용하지 않는 경우
   - Masquerade ON/OFF 비교
   - Masquerade, Reverse Proxy에서 주의할 점

 

---

1. VPN과 Tunnel

VPN은 Virtual Private Network의 약자다.

물리적으로 떨어진 장비나 네트워크를 기존 네트워크 위에서 논리적으로 연결한다.

 

예를 들어 서로 다른 네트워크에 Laptop과 Server가 있다고 하자.

Laptop → Internet → Server

두 장비 사이에는 이미 인터넷이라는 기존 네트워크가 존재한다.

 

VPN은 이 물리적인 네트워크 자체를 새로 만드는 것이 아니다.

VPN은 기존 네트워크 위에 장비나 네트워크 사이의 논리적인 통신 경로를 만든다.

 

Tunnel과 Encapsulation

VPN에서는 원래 전달하려는 패킷을 다른 패킷 안에 넣어 기존 네트워크를 통해 전달할 수 있다.

이를 캡슐화(Encapsulation)라고 한다.

WireGuard Tunnel과 패킷 캡슐화

 

Underlay Network는 Tunnel 내부에서 어떤 주소를 사용하는지 알 필요가 없다.

Underlay Network에서는 암호화·캡슐화된 외부 패킷을 Tunnel Endpoint 사이에 전달하면 된다.

목적지 Tunnel Endpoint에 도착하면 외부 Header를 제거하고 내부의 원래 패킷을 다시 꺼낸다.

원래 IP Packet → 암호화·캡슐화 → 기존 Network를 통해 전달 → 복호화·역캡슐화 → 원래 IP Packet

 

즉 Tunnel은 새로운 물리적인 선을 만드는 것이 아니라 기존 네트워크를 이용해 그 위에 별도의 논리적인 통신 경로를 만드는 방식이다.

VPN Tunnel을 구현하는 Protocol에는 여러 가지가 있고, 그중 하나가 WireGuard다.

---

2. WireGuard는 패킷을 어떻게 전달하는가

WireGuard는 IP 패킷을 암호화하고 UDP로 캡슐화해 다른 Peer로 전달하는 VPN Protocol이다.

운영체제에는 wg0 같은 WireGuard Network Interface를 만들 수 있다.

 

예를 들어 두 Peer가 다음과 같이 구성되어 있다고 하자.

Peer	기존 Network Interface	WireGuard Interface
Peer A	eth0: 192.168.1.10	wg0: 10.100.0.1
Peer B	eth0: 10.0.0.10	wg0: 10.100.0.2

 

eth0은 기존 네트워크에 연결된 Interface이고,
wg0은 WireGuard 통신을 위한 가상 Network Interface다.

 

1. 애플리케이션이 10.100.0.2로 패킷을 보내면 운영체제의 Routing Table이 먼저 목적지에 맞는 Route를 선택한다.
2. 해당 Route의 출력 Interface가 wg0이라면 원래 IP 패킷은 WireGuard Interface로 전달된다.
3. WireGuard는 목적지 IP와 AllowedIPs를 비교해 전달할 Peer를 선택하고, 원래 패킷을 암호화한 뒤 해당 Peer의 Endpoint를 목적지로 하는 UDP 패킷을 새로 만든다.
   - 예를 들어 Peer B의 Endpoint가 198.51.100.20:51820이라면, 암호화된 Outer Packet의 목적지는 이 주소가 된다.
4. 이 Outer Packet은 다시 운영체제의 일반 Routing Table을 거친다. 운영체제는 198.51.100.20까지 가는 Route를 찾고, eth0이나 Wi-Fi 같은 실제 Underlay Network Interface를 통해 패킷을 전송한다.

즉 패킷은 다음 두 단계의 Routing을 거친다고 볼 수 있다.

• 원래 패킷: 10.100.0.2 → Routing Table → wg0
• 암호화된 Outer Packet: 198.51.100.20:51820 → Routing Table → eth0 → Network

따라서 wg0, Endpoint, eth0 의미는 다음과 같다.

• wg0: 원래 패킷이 들어가는 WireGuard 가상 Interface
• Endpoint: 암호화된 UDP 패킷을 보낼 상대 Peer의 실제 주소와 Port
• eth0: Endpoint까지 UDP 패킷을 실제 네트워크로 전송하는 Interface

 

Peer와 Key

WireGuard에서는 통신 상대를 Peer라고 한다.

각 WireGuard Interface는 자신의 Private Key를 가지고 있으며, 상대 Peer는 Public Key를 통해 식별한다.

구성	역할
Private Key	자신의 장비에서 비밀로 보관
Public Key	상대가 해당 Peer를 식별할 때 사용
Peer	WireGuard가 암호화 통신할 상대

 

예를 들어 Peer A에서 Peer B를 다음과 같이 설정할 수 있다.

[Peer]
PublicKey = PEER_B_PUBLIC_KEY
AllowedIPs = 10.100.0.2/32

PublicKey는 단순히 암호화에 사용할 Key를 지정하는 것뿐 아니라 이 설정이 어떤 Peer에 대한 것인지 식별하는 기준이 된다.

Public Key를 기반으로 Peer 사이에 암호화 상태가 만들어지고, 실제 데이터 패킷은 이 과정에서 만들어진 세션 Key를 이용해 암호화된다.

 

AllowedIPs와 Cryptokey Routing

Peer가 여러 개라면 WireGuard는 wg0으로 들어온 패킷을 어느 Peer에게 보내야 하는지도 결정해야 한다.

이를 위해 사용하는 핵심 설정이 AllowedIPs다.

[Peer]
PublicKey = PEER_B_PUBLIC_KEY
AllowedIPs = 10.100.0.2/32

이 설정은 Peer B의 Public Key와 10.100.0.2/32 Prefix를 연결한다.

Peer와 AllowedIPs 관계

송신할 때 WireGuard는 Destination IP와 각 Peer의 AllowedIPs를 비교해 어떤 Peer로 보낼지 결정한다.

일치하는 Peer를 찾으면 해당 Peer와 연결된 암호화 상태를 이용해 패킷을 전송한다.

 

반대로 패킷을 수신한 뒤에는 복호화된 Packet의 Source IP가 해당 Peer의 AllowedIPs에 포함되는지 확인한다.

방향	AllowedIPs의 역할
송신	Destination IP를 어느 Peer와 연결할지 결정
수신	복호화된 Packet의 Source IP가 해당 Peer에 허용된 주소인지 확인

 

Public Key와 IP Prefix를 연결해 Peer를 선택하고 검증하는 이 구조를 WireGuard에서는 Cryptokey Routing이라고 한다.

 

운영체제 Routing Table과 AllowedIPs의 차이

운영체제의 Routing Table과 WireGuard의 AllowedIPs는 비슷해 보이지만 서로 다른 단계에서 동작한다.

Destination IP → 운영체제 Routing Table → wg0 선택 → WireGuard AllowedIPs → Peer 선택

단계	결정하는 것
운영체제 Routing Table	Destination에 사용할 Route와 출력 Interface, 필요한 경우 Next Hop
WireGuard AllowedIPs	wg0으로 전달된 Packet을 어떤 Peer와 연결할지

 

즉 AllowedIPs가 운영체제의 Routing Table 자체를 대신하는 것은 아니다.

운영체제가 먼저 일반적인 IP Routing을 통해 패킷을 WireGuard Interface로 보내고, 그 안에서 AllowedIPs를 이용해 Peer가 선택된다고 이해하면 된다.

 

Endpoint는 실제 패킷을 보낼 주소다

AllowedIPs를 통해 목적지가 Peer B와 연결된다는 사실을 알았더라도 실제 UDP Packet을 어디로 보낼지는 별도로 알아야 한다.

 

예를 들어 Peer B의 WireGuard UDP Socket에 다음 주소로 접근할 수 있다고 하자.

198.51.100.20:51820

 

Peer A에서는 이 주소를 Endpoint로 설정할 수 있다.

[Peer]
PublicKey = PEER_B_PUBLIC_KEY
AllowedIPs = 10.100.0.2/32
Endpoint = 198.51.100.20:51820

설정	역할
PublicKey	통신할 Peer를 식별
AllowedIPs	해당 Peer와 연결할 IP Prefix
Endpoint	암호화된 WireGuard UDP Packet을 실제로 전달할 주소와 Port

 

전체 송신 과정은 다음 순서로 연결된다.

Application → Destination IP → OS Routing Table → wg0 → AllowedIPs → Peer 선택 → 암호화 → Endpoint로 UDP 전송

 

Endpoint와 WireGuard Interface IP의 차이

WireGuard의 Endpoint와 Interface IP 차이

WireGuard를 처음 볼 때 가장 혼동하기 쉬운 부분이 논리적인 Interface IP와 실제 Endpoint 주소다.

구분	Peer A	Peer B
Endpoint	203.0.113.10:51820	198.51.100.20:51820
WireGuard Interface IP	10.100.0.1	10.100.0.2

 

WireGuard Interface IP는 운영체제의 wg0 같은 Interface에 할당한 IP 주소다.

논리적인 WireGuard Network에서 애플리케이션이 통신할 때 이 주소를 사용한다.

WireGuard 자체에 별도의 Tunnel IP라는 독립적인 설정 항목이 있는 것은 아니다.

 

반면 Endpoint는 암호화된 WireGuard UDP Packet을 실제 Underlay Network에서 전달할 주소와 Port다.

Endpoint는 반드시 공인 IP일 필요는 없다.

 

현재 네트워크에서 상대 Peer의 WireGuard UDP Socket에 도달할 수 있다면 사설 IP나 DNS 이름도 사용할 수 있다.

실제 Packet에는 Inner와 Outer 두 계층의 주소가 함께 존재한다.

[Inner IP Packet]
SRC = 10.100.0.1
DST = 10.100.0.2

[Outer UDP Packet]
SRC = 203.0.113.10:51820
DST = 198.51.100.20:51820

Payload
└─ 암호화된 Inner IP Packet

이 Inner와 Outer의 구분을 이해하면 다음에 나오는 Underlay와 Overlay Network도 자연스럽게 연결된다.

---

3. Underlay와 Overlay Network, 그리고 NetBird

Underlay Network 위에 만들어진 WireGuard/NetBird Overlay Network

Underlay Network와 Overlay Network

WireGuard의 암호화된 UDP Packet이 실제로 이동하는 기존 네트워크를 Underlay Network라고 볼 수 있다.

Ethernet, Wi-Fi, Internet, Cloud VPC 같은 기존 IP Network가 이에 해당할 수 있다.

 

예를 들어 실제 Packet은 다음 Endpoint 사이에서 이동한다.

Peer A 203.0.113.10 → Internet → Peer B 198.51.100.20

 

그 위에서는 WireGuard Interface를 이용해 별도의 논리적인 주소 공간을 만들 수 있다.

Peer A 10.100.0.1 → WireGuard → Peer B 10.100.0.2

 

이처럼 기존 네트워크 위에 구성된 논리적인 네트워크를 Overlay Network라고 한다.

구분	의미	예
Underlay Network	실제 Packet이 이동하는 기존 Network	LAN, Internet, VPC
Overlay Network	Underlay 위에 구성된 논리적인 Network	WireGuard / NetBird의 Overlay 주소 공간

 

NetBird가 WireGuard Peer를 관리하는 방법

Peer가 두 대 정도라면 각 장비의 WireGuard 설정을 직접 관리할 수도 있다.

 

하지만 Peer 수가 계속 늘어나면 각 장비에서 관리해야 하는 정보도 함께 증가한다.

각 Peer의 Public Key, Endpoint, AllowedIPs뿐 아니라 누가 누구와 통신할 수 있는지에 대한 정책도 관리해야 한다.

 

NetBird는 이런 WireGuard 기반 Peer들을 하나의 Private Overlay Network에 참여시키고 Peer 정보와 연결, 접근 정책을 관리할 수 있는 관리 계층을 제공한다.

 

• 즉 WireGuard가 실제 암호화된 Packet을 전달하는 Data Plane을 구성한다면,
• NetBird는 여러 Peer와 Network를 운영하기 위한 관리 기능을 추가한다고 볼 수 있다.

---

4. Routing Peer로 Private Network에 접근하기

모든 자원을 직접 Peer로 만들 수 없는 이유

다음과 같은 Private Network가 있다고 하자.

10.20.0.0/24 대역 안에 Database, Legacy Server, Network Device, Internal API 등이 존재한다.

 

모든 장비에 NetBird Client를 설치할 수 있다면 각각을 Overlay Network의 Peer로 참여시키는 방법도 있다.

하지만 실제 환경에서는 모든 자원에 Client를 직접 설치할 수 있는 것은 아니다.

• Network 장비
• Embedded Device
• Legacy Server
• Database Appliance

이런 자원에 접근하려면 NetBird Peer 중 하나가 Overlay Network와 해당 Private Network 사이에서 Router처럼 패킷을 전달해야 한다.

 

Network Resource와 Routing Peer

Overlay Network에서 Private Network로 Packet을 전달하는 Peer를 Routing Peer라고 한다.

NetBird Routing Peer — Private Network 연결 구조

예를 들어 Client Peer가 10.20.0.50에 접근한다고 하자.

Client Peer → NetBird Overlay → Routing Peer → Private Network → 10.20.0.50

Routing Peer는 NetBird Client가 설치되지 않은 Private Network의 자원으로 Packet을 대신 전달한다.

 

현재 글에서 사용하는 NetBird 구성에서는 Network에 접근 대상 Resource를 등록하고, 해당 Network에 Routing Peer를 연결한다.

예를 들어 10.20.0.0/24 전체를 하나의 Network Resource로 구성할 수 있다.

 

이는 하나의 Host가 아니라 해당 Prefix에 포함되는 Network 전체를 의미한다.

 

Client Peer가 이 Prefix에 포함되는 주소로 Packet을 보내면 Routing Peer를 통해 Private Network로 전달된다.

Network Resource는 접근할 대상이고,
Routing Peer는 해당 Resource가 있는 Network까지 Packet을 전달하는 Router 역할을 한다.

---

5. Routing Peer와 Masquerade

Routing Peer가 Overlay Network의 Packet을 Private Network로 전달할 때는 응답 Packet이 어떻게 돌아올 것인가도 함께 고려해야 한다.

 

다음과 같은 주소를 사용한다고 하자.

장비	주소
Client Peer	100.100.1.10
Routing Peer Overlay IP	100.100.1.20
Routing Peer LAN IP	10.20.0.1
Server	10.20.0.50

 

Client가 Server로 보내는 원래 Packet은 다음과 같다.

SRC = 100.100.1.10
DST = 10.20.0.50

Routing Peer가 Source IP를 변경하지 않고 전달하면 Server도 Source를 100.100.1.10으로 본다.

문제는 응답이다.

 

Server 또는 해당 Network의 Gateway가 100.100.1.10으로 돌아가는 경로를 알고 있어야 응답을 다시 Routing Peer로 보낼 수 있다.

 

Private Network에 NetBird Overlay Prefix로 돌아가는 Route가 없다면 응답 Packet이 올바른 경로로 돌아가지 못할 수 있다.

이 Return Route 구성을 단순하게 만드는 방법이 Masquerade다.

 

Masquerade를 사용하는 경우

Masquerade를 사용하면 Routing Peer가 Private Network로 Packet을 전달하면서 Source IP를 자신의 LAN-side IP로 변경한다.

상태	Source IP	Destination IP
Masquerade 적용 전	100.100.1.10	10.20.0.50
Masquerade 적용 후	10.20.0.1	10.20.0.50

 

이것은 Source NAT(SNAT)의 한 형태다.

NetBird Routing Peer의 Masquerade ON/OFF 비교

Server 입장에서는 요청이 Client Peer가 아니라 10.20.0.1인 Routing Peer에서 들어온 것처럼 보인다.

Server는 같은 Private Network에 있는 Routing Peer로 응답하면 되므로 Overlay Network에 대한 별도의 Return Route를 몰라도 된다.

 

Masquerade를 사용하지 않는 경우

Masquerade를 끄면 원래 Overlay Source IP가 유지된다.

SRC = 100.100.1.10
DST = 10.20.0.50

따라서 Server나 Firewall에서는 어떤 Client Peer가 요청했는지 Source IP를 기준으로 구분할 수 있다.

 

이 정보는 다음과 같은 경우에 유용하다.

• Audit Log에서 원래 Client를 확인해야 하는 경우
• Firewall에서 Peer별 정책을 적용하는 경우
• Source IP 기반 접근 제어가 필요한 경우
• 접속자를 원본 Overlay IP로 추적해야 하는 경우

대신 Private Network에는 NetBird Overlay Prefix로 돌아가는 Return Route가 필요하다.

NetBird Overlay CIDR → Routing Peer의 LAN IP

 

Masquerade ON/OFF 비교

항목	Masquerade ON	Masquerade OFF
Source IP	Routing Peer LAN IP로 변경	원래 Peer Overlay IP 유지
Return Route	일반적으로 별도 구성 불필요	필요
원본 Source IP 확인	어려움	가능
운영 복잡도	낮음	높음
적합한 경우	단순한 Private Network 연결	Audit, Firewall 등에서 원본 IP가 필요한 경우

 

Masquerade, Reverse Proxy에서 주의할 점

앞선 글에서는 Reverse Proxy가 Client IP를 X-Real-IP나 X-Forwarded-For 같은 HTTP Header를 이용해 Backend로 전달할 수 있다고 살펴봤다.

 

Reverse Proxy는 자신에게 도착한 Client의 주소를 알고 있기 때문이다.

Client → Reverse Proxy → Forwarded Header → Backend

 

하지만 Reverse Proxy에 도착하기 전에 Routing Peer에서 Masquerade가 적용됐다면 상황이 달라진다.

 

예를 들어 Source IP가 다음처럼 변경될 수 있다.

100.100.1.10 → Masquerade → 10.20.0.1 → Reverse Proxy

 

Reverse Proxy가 실제 연결에서 관찰하는 Source IP는 이미 10.20.0.1이다.

따라서 Proxy가 자신이 관찰한 주소를 기반으로 Header를 생성하면 다음과 같이 전달된다.

X-Real-IP: 10.20.0.1

 

원래 Overlay IP인 100.100.1.10은 Network Layer에서 이미 다른 주소로 변경된 상태다.

 

따라서 앞단에서 원래 주소를 별도의 방식으로 전달하지 않는다면 Reverse Proxy나 뒤쪽 Application이 원래 Source IP를 Packet만 보고 복원할 수 없다.

 

구분	동작 위치	Client IP 관점
Reverse Proxy	HTTP 요청 처리	자신이 관찰한 Client IP를 Header로 전달 가능
Masquerade	IP Routing 과정의 Source NAT	Packet의 Source Address 자체를 변경

 

결국 WireGuard와 NetBird의 통신 문제를 추적할 때는 각각의 기능 이름을 따로 외우기보다 Packet이 실제로 어떤 경로를 지나가는지를 따라가는 것이 중요하다.

• 처음 Destination IP는 무엇인가
• 운영체제 Routing Table에서 어떤 Route와 Interface가 선택됐는가
• AllowedIPs를 통해 어떤 Peer가 선택됐는가
• 해당 Peer의 실제 Endpoint는 어디인가
• Private Network에 접근할 때 어떤 Routing Peer를 지나는가
• 중간에 Masquerade가 적용되어 Source IP가 변경되는가
• 응답 Packet은 어떤 Route를 통해 돌아오는가

이 흐름을 따라가면 VPN, WireGuard, NetBird, Routing Peer와 Masquerade를 각각 독립적인 기능으로 외우지 않고 하나의 IP Packet이 목적지까지 이동하는 과정으로 연결해서 이해할 수 있다.