2023년에 공유기 2대로 두 사무실을 연결한 글을 올렸는데, 지금은 3대로 늘려서 세 지역을 하나의 네트워크처럼 쓰고 있습니다. 실제 운영 중인 구성 기준으로 전면 개정했습니다.
사무실이나 집이 여러 곳으로 나뉘면 “저쪽 NAS에 있는 파일 좀 열어줘”, “저쪽 프린터로 출력하고 싶은데” 같은 요청이 매일 생깁니다. 여러 지역을 하나의 네트워크로 묶는 방법은 전용회선, 전용 VPN 라우터, 클라우드 VPN 등 여러 가지가 있지만, 여기서는 가장 저렴한 방법인 ipTIME 공유기끼리 WireGuard VPN으로 직접 연결하는 방식을 정리합니다. 추가 장비나 월 비용 없이 공유기만으로 구성됩니다.
연결 방법 비교
| 방식 | 비용 | 난이도 | 비고 |
|---|---|---|---|
| 통신사 전용회선 | 월 수십만 원 이상 | 낮음(업체 시공) | 가장 안정적이지만 소규모에는 과함 |
| 전용 VPN 라우터 (MikroTik, UniFi 등) | 장비비 수십만 원 | 높음 | 기능은 풍부하지만 설정이 복잡 |
| Tailscale / ZeroTier 서브넷 라우터 | 무료~유료 | 중간 | 공인 IP 불필요. 상시 켜진 기기 필요 |
| ipTIME 공유기 VPN | 공유기 값만 | 낮음 | 이 글의 방법 |
전체 구성

| 역할 | 내부 대역 | 모델 | WireGuard 서버 터널 주소 |
|---|---|---|---|
| 지점 A | 192.168.45.0/24 | A3004TW | 10.0.37.1 |
| 허브 | 192.168.10.0/24 | A3008-MU | 10.0.195.1 |
| 지점 B | 192.168.0.0/24 | A5004NS-M | 10.0.180.1 |
- 세 대 모두 펌웨어 15.36.6
- 허브를 중심으로 지점 A, 지점 B가 연결되는 허브 앤 스포크 구조
- 공유기마다 WireGuard 서버와 클라이언트를 동시에 사용
- 허브와 각 지점 사이에 방향별로 터널 1개씩, 총 4개



허브 앤 스포크 구조란
허브 앤 스포크(Hub and Spoke)는 자전거 바퀴에서 온 이름입니다. 가운데 축(허브)이 있고, 바큇살(스포크)이 축에서 바깥으로 뻗어 나가는 모양입니다. 네트워크에서는 모든 지점이 중앙의 허브 한 곳에만 연결되고, 지점끼리는 허브를 거쳐 통신하는 구조를 말합니다.
항공 노선을 떠올리면 쉽습니다. 지방 공항끼리 모두 직항을 만드는 대신, 인천 같은 허브 공항 한 곳에 노선을 모으고 환승으로 연결하는 방식입니다. 반대로 모든 지점을 서로 직접 연결하는 구조는 풀메시(Full Mesh)라고 부릅니다.

| 항목 | 허브 앤 스포크 | 풀메시 |
|---|---|---|
| 연결 수 (지점 n곳) | n−1 | n(n−1)/2 |
| 지점 추가 시 작업 | 허브와 새 지점만 연결 | 기존 모든 지점과 연결 |
| 지점 간 경로 | 허브 경유 | 직접 |
| 지점 간 속도 | 허브 회선·공유기에 좌우 | 두 지점 회선에만 좌우 |
| 허브 장애 시 | 전체 지점 간 통신 중단 | 해당 지점만 영향 |
| 관리 | 허브 한 곳 중심으로 단순 | 지점이 늘수록 급격히 복잡 |
이 글의 구성에서는 192.168.10.0/24 공유기가 허브, 192.168.45.0/24와 192.168.0.0/24 공유기가 스포크입니다. ipTIME에서는 허브와 지점 사이에 방향별로 터널을 하나씩 두기 때문에, 실제 터널 수는 연결 수의 두 배입니다. 지점 3곳이면 허브 앤 스포크는 터널 4개, 풀메시는 6개가 필요합니다.
허브를 고르는 기준
- 인터넷 회선이 가장 빠르고 안정적인 곳
- 공인 IP 또는 DDNS 접속이 안정적인 곳
- 공유기가 항상 켜져 있는 곳
- 가능하면 CPU 성능이 가장 좋은 공유기
풀메시가 나은 경우
- 지점끼리 대용량 파일 전송이 잦은 경우
- 허브 장애로 전체가 끊기는 상황을 허용할 수 없는 경우
두 방식을 섞을 수도 있습니다. 기본은 허브 앤 스포크로 두고, 트래픽이 많은 두 지점 사이에만 직접 터널을 추가하는 방식입니다.
왜 터널을 방향별로 하나씩 만드나
처음 2대로 연결했을 때 가장 헷갈린 부분입니다. 한쪽을 서버, 다른 쪽을 클라이언트로 연결하면 클라이언트 쪽에서는 상대 네트워크가 보이는데, 서버 쪽에서는 클라이언트 뒤의 네트워크로 들어가지 못하는 상황이 생깁니다.
상대 대역으로 가는 경로는 WireGuard 클라이언트를 가진 쪽에서 “클라이언트 사용 관리”로 지정합니다. 서버 쪽에는 클라이언트 뒤의 네트워크로 가는 경로를 지정할 곳이 없습니다. 그래서 규칙은 단순합니다. “내가 가고 싶은 쪽의 서버에 내가 클라이언트로 붙는다.”
- 지점 → 허브: 지점 공유기가 허브 서버에 클라이언트로 접속 (터널 10.0.195.x)
- 허브 → 지점: 허브 공유기가 각 지점 서버에 클라이언트로 접속 (터널 10.0.37.x, 10.0.180.x)
1단계. IP 대역 분리
ipTIME은 기본값이 모두 192.168.0.1이기 때문에, 그대로 두면 네트워크가 충돌해서 라우팅이 불가능합니다. 공유기마다 서로 다른 대역을 써야 합니다. 이 구성에서는 45, 10, 0 세 대역을 사용합니다.
대역을 바꾸면 기존에 고정 IP로 설정한 프린터나 NAS 주소도 함께 바뀌므로, 사용자가 적은 시간에 작업하는 것이 좋습니다.
2단계. 각 공유기에 WireGuard 서버 켜기
세 대 모두 VPN 설정 → WireGuard 서버 설정에서 서버를 활성화합니다.
- DDNS 등록 (ipTIME DDNS). 공인 IP가 바뀌어도 접속 주소 유지
- 포트는 기본값 51820 대신 공유기마다 다른 포트 사용
- 통신사 모뎀 뒤에 공유기가 있는 이중 NAT 환경이면 모뎀에서 해당 UDP 포트 포워딩 필요
- 피어 추가 직후 나오는 설정 화면은 닫으면 다시 볼 수 없으므로 설정 파일을 먼저 내려받기
허브 서버에는 지점 공유기 2대가 피어로 등록됩니다. 같은 서버에 노트북, 폰, 태블릿, 클라우드 서버도 함께 등록해서 쓰고 있습니다. 서버 하나로 사이트 간 연결과 개인 기기 원격 접속을 동시에 처리하는 구조입니다.

3단계. WireGuard 클라이언트 연결
지점 쪽: 각 지점 공유기의 WireGuard 클라이언트에 허브 서버를 등록합니다.


허브 쪽: 허브 공유기의 WireGuard 클라이언트에 지점 A, 지점 B 서버를 각각 등록합니다.

4단계. 클라이언트 사용 관리에서 목적지 라우팅
터널만 연결해서는 상대 대역으로 트래픽이 가지 않습니다. VPN 설정 → 클라이언트 사용 관리에서 “이 목적지로 가는 트래픽은 이 터널로” 규칙을 추가합니다.
- 단말: 전체 (내부 모든 기기에 적용)
- 목적지: 상대 대역 (예: 192.168.10.0/24)
- VPN: 해당 WireGuard 클라이언트
지점 A의 설정입니다. 허브 대역뿐 아니라 지점 B 대역까지 허브 터널로 보내도록 두 개의 규칙을 넣었습니다.

| 목적지 | 사용 터널 |
|---|---|
| 192.168.10.0/24 (허브) | 허브로 가는 클라이언트 |
| 192.168.0.0/24 (지점 B) | 허브로 가는 클라이언트 |
다른 공유기에서 다른 지점으로 가야 할 때도 같은 원리로, 가려는 대역을 해당 방향의 클라이언트 터널로 보내는 규칙을 추가하면 됩니다.
목적지를 지정하는 방식이라 지정한 대역만 VPN을 타고, 일반 인터넷 트래픽은 각 지점 회선으로 그대로 나갑니다. 모든 트래픽을 허브로 보내는 것이 아니기 때문에 지점 인터넷 속도에는 영향이 없습니다.
5단계. 연결 확인
2대 구성과 달리 3대 구성에서는 지점 A에서 지점 B로 가는 경로가 핵심입니다. 두 지점 사이에는 직접 터널이 없지만, 4단계에서 지점 B 대역을 허브 터널로 보내도록 했기 때문에 허브를 거쳐 접속됩니다. traceroute로 경로를 확인해봤습니다.

| 홉 | 주소 | 의미 |
|---|---|---|
| 1 | 10.0.37.1 | 지점 A 공유기 |
| 2 | 10.0.195.1 | 허브 공유기 |
| 3 | 10.0.180.1 | 지점 B 공유기 |
| 4 | 192.168.0.68 | 목적지 기기 |
지점 A → 허브 → 지점 B 순서로 허브가 두 터널 사이를 중계하고 있습니다. 지점 A는 라우팅 규칙에 따라 지점 B행 패킷을 허브 터널로 보내고, 허브는 자신의 라우팅 규칙에 따라 지점 B로 가는 클라이언트 터널로 넘깁니다.
덕분에 지점끼리 직접 터널을 만들지 않아도 됩니다. 지점이 늘어나도 터널은 허브와 새 지점 사이에 2개만 추가하고, 나머지는 기존 지점에 새 대역의 라우팅 규칙 한 줄씩 넣으면 됩니다. 모든 지점끼리 직접 연결하는 풀메시였다면 3대에서 터널 6개, 4대에서 12개가 필요했을 것입니다.
허브 경유의 단점
- 지점끼리 트래픽이 허브 회선의 다운로드와 업로드를 모두 사용
- 허브 공유기가 암복호화를 두 번 수행하므로 지점 간 속도는 허브 연결보다 낮음
- 허브 공유기나 허브 회선이 멈추면 지점끼리도 끊김
지점끼리 대용량 전송이 잦다면 해당 지점 사이에만 직접 터널을 추가하는 방식으로 보완할 수 있습니다.
속도: L2TP vs WireGuard
2023년 2대 구성 당시, 같은 회선과 같은 공유기에서 프로토콜만 바꿔 측정한 결과입니다.
| 프로토콜 | 다운로드 | 업로드 |
|---|---|---|
| L2TP | 16.3 Mbps | 26.7 Mbps |
| WireGuard | 102 Mbps | 132 Mbps |
측정은 허브 LAN에 설치한 OpenSpeedTest 서버(192.168.10.100)에 다른 지점에서 VPN으로 접속해서 진행했습니다.


Ping 차이는 1ms 정도로 거의 같지만, 처리량은 약 5~6배 차이가 납니다. L2TP/IPsec은 암호화 처리가 무거워서 공유기 CPU가 먼저 한계에 걸리기 때문입니다. 공유기끼리 연결하는 용도라면 WireGuard를 쓰지 않을 이유가 거의 없습니다. L2TP는 별도 앱 없이 윈도우·맥·스마트폰 기본 기능으로 접속해야 하는 경우에 대안으로 쓰는 것이 맞습니다.
VPN 속도의 상한은 양쪽 회선 중 느린 쪽의 업로드 속도와 공유기 CPU 성능입니다.
자주 막히는 문제
VPN은 연결됐는데 상대 PC에 ping이 안 감
- 원인 대부분이 윈도우 방화벽. 윈도우는 기본적으로 ping(ICMP)과 파일 공유를 “로컬 서브넷”에서만 허용
- 해결: 방화벽 인바운드 규칙의 원격 IP 범위에 상대 대역 추가
한쪽에서만 접속되고 반대쪽에서는 안 됨
- 목적지 라우팅은 클라이언트를 가진 쪽에서만 지정 가능
- 해결: 반대 방향으로도 클라이언트 터널 추가 (이 글의 방향별 터널 구조)
네트워크 탭에 상대 지역 PC가 안 보임
- 네트워크 검색은 브로드캐스트 기반이라 다른 대역으로 넘어가지 않는 것이 정상
- 해결:
\\IP주소로 직접 접속하거나 네트워크 드라이브로 연결
허브는 되는데 다른 지점으로는 안 됨
- 지점의 클라이언트 사용 관리에 다른 지점 대역 규칙이 빠진 경우
- 해결: 다른 지점 대역도 허브 터널로 보내는 규칙 추가
클라이언트가 서버에 아예 접속을 못 함
- 이중 NAT 여부와 포트포워딩 확인
- DDNS 주소가 현재 공인 IP를 가리키는지 확인
- 공인 IP가 아닌 사설 IP를 할당받는 회선(CGNAT)이면 서버 역할을 다른 쪽으로 옮기거나 Tailscale 같은 방식 검토
속도가 기대보다 낮음
- 저가형 모델은 CPU가 병목. 양쪽 업로드 속도도 확인
보안 팁
- 외부에 여는 포트는 WireGuard 포트만
- 기본 포트 대신 공유기마다 다른 포트 사용
- 피어 설정 파일에는 개인키가 들어 있으므로 메신저 등에 남기지 않기
- 사용하지 않는 피어는 삭제
- 공유기 관리자 페이지 원격 관리 기능은 끄기
- 펌웨어 최신 버전 유지
마무리
ipTIME 공유기만으로도 여러 지역을 하나의 네트워크처럼 묶을 수 있습니다. 핵심은 세 가지입니다. 대역을 겹치지 않게 나누고, 가고 싶은 방향으로 클라이언트 터널을 만들어 목적지 라우팅을 걸고, 지점이 여러 개면 허브를 두어 중계하게 하는 것입니다. 지점이 늘어나도 터널 2개와 라우팅 규칙 몇 줄만 추가하면 되기 때문에, 확장도 어렵지 않습니다.


















