OpenWrt 공유기를 VPN 게이트웨이로 구성하면 집 안의 여러 기기에 VPN 앱을 하나씩 설치하지 않고도 트래픽 흐름을 중앙에서 관리할 수 있습니다. 노트북, 스마트폰, 태블릿, TV, 게임 콘솔처럼 클라이언트 설치가 어렵거나 설정을 통일하기 힘든 기기도 공유기의 라우팅 정책을 따르게 만들 수 있다는 점이 핵심입니다.
다만 공유기 전체 트래픽을 무조건 VPN으로 보내는 방식이 항상 최선은 아닙니다. 국내 서비스, 금융 사이트, 프린터와 NAS처럼 직접 연결이 더 적합한 대상까지 우회하면 속도 저하나 접속 오류가 생길 수 있습니다. 따라서 먼저 네트워크 구조를 정하고, 필요한 목적지·기기·포트만 VPN으로 보내는 정책 기반 라우팅을 적용하는 편이 관리하기 쉽습니다. 이 글에서는 OpenWrt 공유기를 중앙 게이트웨이로 활용하는 절차와 점검 방법을 단계별로 설명합니다.
OpenWrt VPN 구성 전 확인할 사항
OpenWrt에서 VPN을 설정하기 전에 가장 먼저 확인할 것은 공유기의 역할입니다. 공유기가 집 안 네트워크의 DHCP 서버이자 기본 게이트웨이여야 모든 기기가 공유기의 라우팅 규칙을 자동으로 사용할 수 있습니다. 인터넷 회선에 연결된 통신사 장비가 라우터 모드로 동작하고 그 뒤에 OpenWrt 공유기가 다시 라우터로 연결된 경우에는 이중 NAT가 생길 수 있습니다. 단순한 웹 접속은 가능하더라도 포트 접근, 로컬 장치 검색, 일부 실시간 통신에서 예상하지 못한 문제가 나타날 수 있으므로 현재 연결 구조를 먼저 기록해 두세요.
90+
지원 국가
200+
제공 회선
5
지원 플랫폼
不限
동시 접속 기기
공유기의 CPU와 메모리도 중요합니다. 암호화와 라우팅을 동시에 처리하므로 오래된 저사양 장치에서는 VPN 연결 후 처리량이 크게 줄거나 여러 기기가 동시에 사용할 때 응답이 불안정해질 수 있습니다. 특정 속도를 보장한다고 단정하기보다, 자신의 회선과 공유기 조합에서 직접 확인해야 합니다. 펌웨어를 변경하기 전에는 현재 설정을 백업하고, 복구 이미지와 유선 관리 방법을 준비하는 것이 안전합니다.
- ✅ OpenWrt 공유기의 LAN 주소와 관리자 접속 방법을 먼저 기록합니다.
- ✅ DHCP 서버와 기본 게이트웨이가 어느 장치에서 동작하는지 확인합니다.
- ✅ VPN을 사용할 기기와 직접 연결할 기기를 목록으로 나눕니다.
- ✅ 현재 WAN 연결, DNS, 무선 네트워크 설정을 백업합니다.
- ❌ 두 개의 VPN 게이트웨이나 프록시 클라이언트를 동시에 기본 경로로 사용하지 않습니다.
프로토콜과 구성 방식 선택하기
OpenWrt에서 사용할 수 있는 방식은 크게 WireGuard·OpenVPN 같은 표준 VPN 터널과, 프록시 코어를 이용한 정책 기반 라우팅으로 나눌 수 있습니다. 어떤 방식이 더 좋은지는 제공받은 설정 형식, OpenWrt 버전, 설치 가능한 패키지와 원하는 분리 규칙에 따라 달라집니다.
| 방식 | 적합한 경우 | 확인할 항목 | 주의점 |
|---|---|---|---|
| WireGuard | 간결한 터널 설정과 낮은 관리 복잡도를 원하는 경우 | 공개 키, 주소, 엔드포인트, 포트, 허용 IP | AllowedIPs를 잘못 지정하면 전체 또는 일부 경로가 의도와 다르게 바뀔 수 있습니다 |
| OpenVPN | 기존 서버 설정이나 인증서 기반 구성이 필요한 경우 | CA 인증서, 클라이언트 인증서, 키, TLS와 암호화 설정 | 설정 항목이 많고 공유기 자원 사용량을 별도로 확인해야 합니다 |
| Shadowsocks·VMess·Trojan | 프록시 노드와 정책 분리를 함께 사용하려는 경우 | 주소, 포트, UUID 또는 비밀번호, TLS·전송 매개변수 | OpenWrt 패키지와 코어가 해당 프로토콜 및 전송 방식을 지원해야 합니다 |
| Hysteria2 | UDP 기반 전송을 지원하는 환경에서 별도 시험이 필요한 경우 | 인증 정보, 서버 이름, 포트와 TLS 관련 설정 | 네트워크와 클라이언트 구현에 따라 결과가 달라지며 이름만으로 성능을 판단할 수 없습니다 |
WireGuard와 OpenVPN 설정 파일은 일반적으로 공유기용 VPN 인터페이스에 직접 입력할 수 있습니다. 반면 Shadowsocks, VMess, Trojan, Hysteria2 등의 노드는 OpenWrt에 설치한 호환 프록시 코어 또는 관리 패키지가 필요합니다. Clash 계열 설정, sing-box 설정, 개별 URI와 일반 VPN 설정 파일은 서로 같은 형식이 아니므로, 구독 링크를 그대로 아무 입력란에 붙여 넣어서는 안 됩니다.
Windows, macOS, Android, iOS, Linux용 공식 앱이나 Clash Verge, Shadowrocket 같은 클라이언트에서 구독 링크를 가져오는 것과 OpenWrt에서 구독을 처리하는 것은 별개의 작업입니다. 공유기에서 직접 구독을 사용하려면 해당 OpenWrt 패키지가 그 형식을 지원하는지 확인해야 하며, 지원하지 않는다면 호환되는 설정 파일로 변환하거나 공유기에서는 WireGuard·OpenVPN처럼 직접 지원되는 방식만 사용하는 편이 낫습니다. 변환 과정에서 인증 정보가 외부 서비스로 전송되지 않는지도 확인해야 합니다.
OpenWrt에서 VPN 인터페이스 만들기
이제 실제 설정 순서를 살펴보겠습니다. 메뉴 이름은 OpenWrt 버전과 설치한 패키지에 따라 다를 수 있지만, 네트워크 인터페이스와 방화벽 영역을 분리한다는 원칙은 같습니다.
- 설정 백업: LuCI에서 현재 설정을 백업하고, 가능하면 공유기에 유선으로 접속할 수 있는 컴퓨터를 준비합니다. 무선만 사용한 상태에서 네트워크를 바꾸면 연결이 끊겼을 때 복구가 어렵습니다.
- VPN 설정 준비: 제공받은 WireGuard 설정 또는 OpenVPN 파일을 확인합니다. 서버 주소, 인증서, 키, DNS, AllowedIPs 같은 항목이 누락되지 않았는지 살펴봅니다.
- 인터페이스 생성: WireGuard라면 개인 키와 터널 주소, 피어의 공개 키와 엔드포인트를 입력합니다. OpenVPN이라면 클라이언트 설정 파일과 인증 자료를 지정합니다.
- 방화벽 영역 연결: VPN 인터페이스를 별도 방화벽 영역에 넣고, LAN에서 VPN 영역으로 나가는 전달만 허용합니다. WAN과 VPN을 동시에 잘못 연결하면 정책이 무시되거나 트래픽이 다른 경로로 빠질 수 있습니다.
- 자동 시작 설정: 공유기 재부팅 후에도 VPN 인터페이스가 자동으로 올라오는지 확인합니다. 자동 시작이 되더라도 실제 터널 인증이 성공했는지 별도로 검사해야 합니다.
- 기본 경로 시험: 처음부터 집 전체에 적용하지 말고 테스트용 기기 하나만 VPN 정책에 포함합니다. 연결 전후의 외부 IP, DNS 응답, 일반 웹 접속과 로컬 장치 접근을 비교합니다.
WireGuard에서 AllowedIPs를 넓게 지정하면 모든 IPv4 또는 IPv6 트래픽이 터널로 향하는 구성이 될 수 있습니다. 반대로 특정 대역만 지정하면 선택한 목적지만 터널을 사용하게 만들 수 있습니다. 이 값은 단순한 서버 주소 목록이 아니라 라우팅 범위를 결정하는 항목이므로, 제공업체의 안내와 OpenWrt의 라우팅 상태를 함께 확인해야 합니다.
IPv6를 사용 중이라면 IPv4만 VPN으로 보내고 IPv6는 WAN으로 빠지는 상황이 생길 수 있습니다. 이 경우 외부 서비스가 두 주소를 다르게 인식하거나, 사용자가 예상하지 않은 경로가 남을 수 있습니다. IPv6를 터널에서 처리할 준비가 되지 않았다면 테스트 단계에서 IPv6 정책을 명확히 정리하고, DNS와 방화벽에서도 같은 기준을 적용하세요.
기기와 도메인별로 트래픽 나누기
정책 기반 라우팅은 “어떤 트래픽을 어느 인터페이스로 보낼 것인가”를 규칙으로 표현합니다. 규칙의 기준은 기기의 고정 IP 또는 MAC 주소, 목적지 IP 대역, 도메인 목록, 프로토콜과 포트가 될 수 있습니다. 처음에는 기준을 하나만 사용해 단순하게 시작하는 것이 좋습니다. 예를 들어 테스트용 노트북만 VPN으로 보내고, 나머지 기기는 WAN에 남겨 두면 문제가 발생했을 때 원인을 좁히기 쉽습니다.
기기별 정책
기기별 분리는 DHCP 예약과 함께 구성하는 것이 안정적입니다. 특정 노트북의 주소가 바뀌면 IP 기반 규칙이 다른 기기에 적용될 수 있으므로, OpenWrt에서 해당 기기에 항상 같은 내부 주소를 배정하세요. 스마트 TV나 게임 콘솔처럼 앱 설정을 직접 바꾸기 어려운 기기는 기기 주소를 기준으로 정책을 만들고, 일반 업무용 컴퓨터는 직접 연결을 기본값으로 두는 방식이 관리하기 쉽습니다.
목적지별 정책
도메인별 분리는 편리하지만 DNS 처리 방식에 영향을 받습니다. 공유기가 도메인 이름을 IP 주소로 해석한 뒤 그 결과를 정책에 반영하는 구조라면 CDN이나 주소 변경 때문에 목록이 오래 유지되지 않을 수 있습니다. 반대로 DNS 요청 자체가 VPN으로 전달되지 않으면 도메인 규칙이 있어도 실제 연결은 직접 경로를 사용할 수 있습니다. 따라서 도메인 규칙을 사용한다면 DNS 포워딩, 캐시, DoH·DoT 사용 여부와 IPv6 응답을 함께 점검해야 합니다.
지역별 IP 목록을 직접 유지하는 방법은 시작하기는 쉽지만 관리 부담이 큽니다. 서비스의 주소가 바뀌거나 여러 CDN을 사용하면 목록이 빠르게 낡을 수 있습니다. 목적지 규칙은 꼭 필요한 범위만 만들고, 넓은 국가 대역을 무조건 추가하기보다 실제 접속 오류가 확인된 대상부터 검토하세요. 포트 기반 분리는 특정 애플리케이션을 구분할 때 유용하지만, 많은 앱이 여러 포트를 사용하거나 HTTPS 안에서 기능을 섞기 때문에 포트 하나만으로 완벽하게 식별된다고 보기는 어렵습니다.
- ✅ 기본 정책은 직접 연결로 두고 필요한 기기나 목적지만 VPN에 추가합니다.
- ✅ 테스트 기기에는 고정 DHCP 주소를 배정해 규칙 대상이 바뀌지 않게 합니다.
- ✅ DNS 요청이 어느 인터페이스로 나가는지 확인한 뒤 도메인 규칙을 사용합니다.
- ✅ VPN 연결이 끊겼을 때 해당 정책의 트래픽을 차단할지 직접 연결로 전환할지 결정합니다.
- ❌ 도메인 하나의 결과를 보고 모든 관련 서비스가 같은 주소 체계를 쓴다고 가정하지 않습니다.
DNS 누수와 연결 실패 점검
VPN 터널이 연결되었다는 표시만으로 모든 트래픽이 올바른 경로에 있다는 뜻은 아닙니다. 외부 IP 확인 페이지는 출구 주소를 보여 줄 뿐이고, DNS 요청이 직접 연결로 나가거나 특정 앱만 WAN을 사용할 가능성까지 알려 주지는 않습니다. 테스트할 때는 VPN 적용 기기와 미적용 기기를 구분하고, 같은 조건에서 외부 IP, DNS 서버, IPv4·IPv6 결과를 각각 확인하세요.
인터넷은 되지만 일부 사이트만 열리지 않는다면 MTU, DNS, TLS 서버 이름, 라우팅 범위를 먼저 살펴볼 수 있습니다. 터널을 통과할 때 패킷 크기가 경로에 맞지 않으면 작은 요청은 성공하고 큰 응답이나 파일 전송만 실패하는 현상이 나타날 수 있습니다. 이때 무작정 여러 설정을 동시에 바꾸지 말고, 먼저 VPN을 해제한 상태의 정상 동작을 확인한 다음 인터페이스와 방화벽 규칙을 한 항목씩 비교하세요.
VPN이 연결되지 않는 경우에는 서버 주소와 포트, 키 또는 인증서, 시스템 시간이 맞는지 확인합니다. Trojan이나 VMess처럼 TLS와 전송 매개변수가 함께 필요한 구성은 서버 이름, 인증 정보와 전송 방식 중 하나만 달라도 연결이 실패할 수 있습니다. Hysteria2처럼 UDP를 사용하는 구성은 공유기 방화벽과 회선 환경에서 UDP가 허용되는지도 확인해야 합니다.
공유기를 재부팅한 뒤 인터넷이 전혀 되지 않는다면 자동 시작된 VPN이 실패했는데도 기본 경로가 VPN으로 고정된 상황일 수 있습니다. 복구를 위해 유선으로 LuCI에 접속하고, VPN 인터페이스를 일시 중지한 뒤 WAN 직접 연결을 되돌립니다. 모든 트래픽을 VPN으로 강제하는 킬 스위치는 개인정보 보호에 도움이 될 수 있지만, 초기 구성에서는 관리 경로까지 차단하지 않도록 예외를 신중히 설계해야 합니다.
자주 묻는 질문
공유기 설정 후 기기별 앱이 필요한가요?
공유기가 해당 기기의 기본 게이트웨이로 동작하고 정책이 올바르게 적용된다면 일반적인 웹 트래픽에는 별도 앱이 필요하지 않습니다. 그러나 기기 자체의 DNS 고정, 별도 프록시, 애플리케이션 전용 VPN이 있으면 공유기 규칙과 충돌할 수 있습니다. 기존 앱의 자동 연결과 프록시 설정을 확인하세요.
모든 집 안 트래픽을 VPN으로 보내도 되나요?
가능한 구성일 수는 있지만 권장되는 기본값은 아닙니다. 로컬 프린터, NAS, 공유 폴더와 일부 국내 서비스는 직접 연결이 더 적합할 수 있습니다. 먼저 테스트 기기와 필요한 목적지만 적용한 뒤, 문제가 없는 범위에서 점진적으로 확대하세요.
구독 링크를 OpenWrt에 바로 붙여 넣어도 되나요?
OpenWrt에 설치한 관리 패키지와 프록시 코어가 해당 구독 형식을 지원할 때만 가능합니다. WireGuard 설정, Clash 형식, sing-box 형식과 개별 프로토콜 URI는 서로 다를 수 있습니다. 지원 형식과 업데이트 방식을 먼저 확인하고, 구독 링크는 계정 권한이 포함될 수 있으므로 공개된 변환 사이트나 채팅방에 입력하지 마세요.
공유기와 공식 클라이언트를 동시에 사용해도 되나요?
기술적으로는 가능하지만 같은 기기에서 두 계층의 VPN이나 프록시를 동시에 활성화하면 경로가 복잡해질 수 있습니다. 공유기에서 이미 VPN을 적용한 기기라면 공식 클라이언트는 먼저 끄고 기준 상태를 확인하세요. 앱별 분리 라우팅이 꼭 필요할 때만 예외적으로 사용하고, 어느 계층이 DNS와 기본 경로를 담당하는지 명확히 기록하는 것이 좋습니다.
OpenWrt를 중앙 VPN 게이트웨이로 활용하는 가장 안정적인 순서는 백업, 인터페이스 구성, 테스트 기기 적용, DNS와 경로 확인, 정책 확대입니다. 공유기 한 대에서 모든 문제를 해결하려 하기보다 직접 연결과 VPN 경로의 역할을 나누고, 규칙을 작게 시작해 로그와 실제 접속 결과를 기준으로 조정하세요. 이렇게 접근하면 기기마다 설정을 반복하지 않으면서도 집 전체 네트워크를 목적에 맞게 관리할 수 있습니다.