OpenWrt에서 VPN 분할 터널링을 설정할 때는 VPN 연결 자체보다 “어떤 트래픽을 어느 경로로 보낼 것인가”를 먼저 설계해야 합니다. 모든 기기를 VPN으로 보내는 방식은 단순하지만, 국내 서비스나 게임, 은행 사이트까지 우회 경로를 사용하면서 접속 문제가 생길 수 있습니다. 반대로 모든 트래픽을 일반 인터넷으로 두면 특정 기기나 서비스만 별도 경로로 보내려는 목적을 달성하기 어렵습니다.
이 글에서는 OpenWrt 공유기에서 기기별 또는 목적지별로 VPN 경로와 일반 인터넷을 나누는 기본 원리, 정책 라우팅 구성, DNS 처리, 적용 확인, 오류 발생 시 복구 순서를 설명합니다. OpenClash·Mihomo 계열, sing-box 기반 도구, PassWall 계열처럼 사용하는 패키지의 이름과 화면은 다를 수 있지만, 핵심은 동일합니다. 먼저 WAN과 VPN 출구를 구분하고, 그다음 정책 우선순위와 DNS 경로를 함께 맞춰야 합니다.
분할 터널링의 구조와 정책 선택
일반적인 OpenWrt 공유기는 WAN 인터페이스를 통해 인터넷에 접속하고, 클라이언트 기기는 LAN 또는 무선 네트워크에 연결됩니다. VPN 클라이언트를 실행하면 tun, tproxy, wg 또는 별도의 가상 인터페이스가 추가될 수 있습니다. 분할 터널링은 이 여러 출구 중 하나를 정책에 따라 선택하는 작업입니다. 예를 들어 특정 기기의 사설 IP 주소를 기준으로 VPN 인터페이스를 선택하거나, 특정 도메인 그룹만 프록시 코어로 보내고 나머지는 WAN으로 유지할 수 있습니다.
OpenWrt에서 자주 사용하는 구성은 크게 세 가지입니다. 첫째, WireGuard나 OpenVPN 같은 터널 인터페이스를 만들고 정책 기반 라우팅 패키지로 소스 주소별 경로를 나누는 방식입니다. 둘째, Mihomo 또는 Clash 계열 코어를 실행해 도메인·IP·기기 규칙을 처리하는 방식입니다. 셋째, sing-box 기반 코어에서 inbound, outbound, route 규칙을 구성하는 방식입니다. 어느 방식이든 기본 경로를 통째로 VPN으로 바꾸는지, 선택한 트래픽만 VPN으로 보내는지부터 확인해야 합니다.
| 분할 기준 | 사용 예 | 장점 | 주의할 점 |
|---|---|---|---|
| 기기별 | TV나 업무용 노트북만 VPN 사용 | 규칙이 단순하고 결과를 확인하기 쉬움 | 기기의 IP 주소가 바뀌면 정책이 빗나갈 수 있음 |
| 목적지별 | 특정 도메인이나 IP 대역만 VPN 사용 | 한 기기에서 일반 서비스와 VPN 서비스를 함께 사용할 수 있음 | 도메인이 실제 IP로 해석되는 과정과 DNS 정책을 함께 관리해야 함 |
| 기기·목적지 조합 | 한 기기의 특정 서비스만 VPN으로 전달 | 가장 세밀한 제어가 가능함 | 규칙 우선순위와 예외 규칙을 꼼꼼하게 점검해야 함 |
| 프로토콜별 | 일부 UDP 또는 TCP 트래픽만 별도 처리 | 특정 애플리케이션의 요구에 맞출 수 있음 | 프로토콜 감지와 애플리케이션 동작 방식에 따라 결과가 달라질 수 있음 |
처음에는 기기별 정책으로 시작하는 것이 좋습니다. 특정 기기 전체를 VPN으로 보내면 DNS와 라우팅이 정상인지 판단하기 쉽기 때문입니다. 기본 구성이 확인된 뒤 목적지별 규칙을 추가하면, 규칙이 적용되지 않은 것인지 VPN 노드가 연결되지 않은 것인지 구분하기가 수월합니다.
- ✅ 먼저 WAN 일반 경로와 VPN 경로의 이름을 기록하세요.
- ✅ 테스트 기기에는 고정 임대 주소를 지정해 정책 대상이 바뀌지 않게 하세요.
- ✅ 기본 정책을 하나 정하고, 예외 규칙은 그 다음에 추가하세요.
- ❌ 처음부터 여러 패키지와 여러 VPN 코어를 동시에 실행하지 마세요.
OpenWrt 클라이언트와 프로토콜 선택
OpenWrt에서 사용할 클라이언트는 구독 형식과 공유기의 처리 능력에 맞춰 선택해야 합니다. WireGuard는 별도 터널 인터페이스를 만들고 정책 라우팅과 결합하기 쉬운 편입니다. OpenVPN도 널리 사용되지만 암호화 방식과 설정 파일에 따라 CPU 사용량이 달라질 수 있습니다. Shadowsocks, VMess, Trojan, Hysteria2 같은 프록시 프로토콜은 일반적으로 sing-box, Mihomo, Xray 계열 코어 또는 이를 포함한 관리 패키지를 통해 처리합니다.
구독 링크를 가져올 때는 링크가 어떤 형식으로 제공되는지 확인하세요. 한 링크가 여러 프로토콜의 노드를 동시에 포함할 수 있지만, OpenWrt 패키지가 해당 형식을 자동으로 해석한다는 뜻은 아닙니다. Clash 형식 YAML을 요구하는 도구, sing-box JSON을 요구하는 도구, WireGuard 설정 파일을 요구하는 도구는 서로 바로 호환되지 않을 수 있습니다. 가져오기가 완료되었다는 메시지보다 실제 노드와 outbound가 생성되었는지, 로그에 구문 오류가 없는지를 확인해야 합니다.
| 구성 방식 | 주요 특징 | 분할 터널링에서 확인할 항목 |
|---|---|---|
| WireGuard | 터널 인터페이스와 피어 설정을 사용함 | AllowedIPs가 전체 대역을 포함하는지, 정책별 라우팅이 이를 덮어쓰는지 확인 |
| OpenVPN | 프로파일과 인증 설정을 이용해 터널을 만듦 | redirect-gateway가 기본 경로를 바꾸는지, 정책 라우팅과 충돌하지 않는지 확인 |
| Mihomo·Clash | 도메인, IP, 규칙 그룹을 기준으로 outbound를 선택함 | mode가 Rule인지, DNS 모드와 TUN 또는 TProxy 구성이 함께 맞는지 확인 |
| sing-box | inbound와 outbound, route 규칙을 분리해 구성함 | rule 순서, DNS server 선택, auto_detect_interface 설정을 점검 |
| Shadowsocks·VMess·Trojan·Hysteria2 | 프록시 코어에서 처리되는 연결 프로토콜 | 코어 버전, 전송 계층, TLS 또는 UDP 지원 여부가 구독 내용과 맞는지 확인 |
관리 화면에서 정책 기반 라우팅 패키지를 사용하는 경우에는 LAN 기기와 VPN 인터페이스가 올바르게 검색되었는지 먼저 봅니다. 패키지에 따라 정책 이름은 다르지만 보통 소스 주소, 목적지 주소, 목적지 포트, 인터페이스 또는 게이트웨이를 지정할 수 있습니다. 반면 프록시 코어의 규칙 엔진을 사용하는 경우에는 “프록시로 보낼 outbound”와 “직접 연결할 outbound”가 각각 존재해야 하며, 마지막 기본 규칙이 예상과 다르지 않은지 확인해야 합니다.
기기와 서비스별 라우팅 규칙 설정
이제 실제 정책을 작성합니다. 먼저 테스트 기기의 주소를 고정하세요. DHCP 임대 목록에서 기기를 확인한 뒤 고정 임대를 지정하거나, 기기 자체에서 임의의 사설 주소를 사용하지 않도록 설정합니다. 주소가 바뀌면 공유기는 같은 기기로 인식하지 못해 규칙이 작동하지 않을 수 있습니다. 기기 이름만으로 정책을 작성할 수 있는 도구라도 내부적으로는 MAC 주소나 IP 주소를 기준으로 처리하는 경우가 있으므로, 저장 후 실제 대상이 표시되는지 확인해야 합니다.
- OpenWrt의 네트워크 또는 DHCP 메뉴에서 테스트 기기를 찾습니다.
- 해당 기기에 고정 임대 주소를 지정하고 네트워크를 다시 연결합니다.
- VPN 터널 또는 프록시 코어가 정상적으로 실행되는지 로그에서 확인합니다.
- 정책 라우팅 메뉴에서 테스트 기기의 주소를 소스 조건으로 추가합니다.
- 목적지 인터페이스를 VPN으로 지정하고 정책을 저장합니다.
- 정책 서비스를 다시 적용한 뒤 테스트 기기에서 연결 상태를 확인합니다.
기기 전체가 아니라 특정 서비스만 VPN으로 보내려면 목적지 조건을 추가합니다. 도메인 이름을 직접 넣는 방식은 관리하기 편하지만, 실제 라우팅은 도메인이 해석된 IP 주소를 기준으로 이루어질 수 있습니다. CDN을 사용하는 서비스처럼 IP가 자주 바뀌는 목적지는 고정 IP 하나만 등록하면 곧 규칙이 낡을 수 있습니다. 이 경우 도메인 집합을 지원하는 코어 또는 DNS 연동 방식이 더 적합합니다.
규칙의 순서는 매우 중요합니다. 예외 규칙을 먼저 두고 넓은 범위의 일반 규칙을 뒤에 배치해야 합니다. 예를 들어 특정 기기의 국내 서비스는 WAN으로 보내고, 그 외 목적지는 VPN으로 보내려는 경우에는 국내 서비스 예외를 먼저 처리해야 합니다. 반대로 “모든 LAN 트래픽을 VPN” 규칙이 앞에 있으면 뒤에 작성한 예외가 도달하지 않을 수 있습니다. 사용하는 패키지가 first-match인지, 우선순위 숫자가 낮을수록 먼저 적용되는지 설명서를 확인하세요.
Clash 또는 Mihomo 계열에서는 DIRECT와 프록시 정책 그룹의 이름이 실제로 존재하는지 확인해야 합니다. sing-box에서는 route 규칙이 올바른 outbound 태그를 가리키는지, DNS 규칙이 별도로 다른 서버를 선택하지 않는지 살펴봐야 합니다. WireGuard에서는 AllowedIPs에 0.0.0.0/0이 포함된 구성과 선택적 대역만 포함된 구성이 결과를 크게 바꿀 수 있습니다. 전체 대역을 터널에 넣었다면 정책 라우팅 도구가 우선순위를 재조정하는지 반드시 확인하세요.
DNS 요청과 애플리케이션 트래픽 맞추기
라우팅 규칙이 맞아도 DNS가 일반 인터넷으로 빠지면 원하는 결과가 나오지 않을 수 있습니다. 기기가 도메인을 일반 DNS 서버에 문의하고, 반환된 주소로 VPN 또는 WAN에 접속하는 과정에서 규칙과 실제 접속 대상이 어긋날 수 있기 때문입니다. 특히 도메인 기반 규칙을 사용할 때는 어떤 DNS 서버가 질의를 처리하는지, 응답이 캐시되는 위치가 어디인지 확인해야 합니다.
OpenWrt에서는 dnsmasq가 LAN 기기의 DNS 요청을 받는 기본 구성으로 자주 사용됩니다. 프록시 코어가 자체 DNS 기능을 제공한다면 dnsmasq가 모든 요청을 코어로 전달하도록 구성하거나, 특정 도메인만 별도 서버로 보내는 방식이 가능합니다. Mihomo에서 fake-ip 또는 redir-host를 사용하는 경우에는 해당 모드가 정책 라우팅과 호환되는지 확인해야 합니다. fake-ip 주소를 일반적인 IP 규칙에 그대로 넣으면 실제 목적지를 판별하지 못할 수 있습니다.
DNS 암호화 기능을 추가할 때도 신중해야 합니다. DoH나 DoT를 사용하면 브라우저가 공유기의 DNS 설정을 우회할 수 있습니다. 브라우저의 보안 DNS, 운영체제의 개인 DNS, 애플리케이션 내부 DNS가 각각 활성화되어 있으면 공유기에서 기록한 질의와 실제 질의가 다를 수 있습니다. 테스트 단계에서는 브라우저의 별도 DNS 기능을 잠시 기본값으로 두고, 공유기 DNS 정책이 먼저 정상 작동하는지 확인하는 편이 좋습니다.
- ✅ LAN 기기가 OpenWrt를 DNS 서버로 사용하고 있는지 확인하세요.
- ✅ 프록시 코어의 DNS 모드와 정책 라우팅의 도메인 판별 방식을 맞추세요.
- ✅ IPv4만 규칙을 작성했다면 IPv6 트래픽이 별도 WAN 경로로 빠지지 않는지 확인하세요.
- ❌ DNS가 정상이라는 이유만으로 애플리케이션의 실제 출구 경로까지 정상이라고 단정하지 마세요.
DNS 확인은 기기에서 nslookup 또는 dig 같은 도구를 사용해 수행할 수 있습니다. 중요한 것은 특정 응답 주소가 좋거나 나쁘다는 판단이 아니라, 질의가 예상한 DNS 서버를 통과하는지와 정책 대상 도메인이 올바르게 분류되는지입니다. 웹 브라우저, 동영상 앱, 게임 런처처럼 자체 연결 방식을 사용하는 프로그램은 브라우저 테스트와 다른 결과를 낼 수 있으므로 실제 사용할 애플리케이션으로도 확인해야 합니다.
적용 후 경로와 출구를 확인하는 방법
설정을 저장한 뒤에는 관리 화면에 성공 메시지가 표시되는 것만으로 충분하지 않습니다. 먼저 테스트 기기의 네트워크를 재연결하거나 DHCP 임대를 갱신해 오래된 DNS와 라우팅 정보를 정리합니다. 그다음 정책 서비스, 프록시 코어, VPN 인터페이스가 모두 실행 중인지 확인합니다. 정책을 적용하는 동안 공유기 관리 화면이 잠시 끊길 수 있으므로, 가능하면 무선 연결만 사용하지 말고 유선 접속 방법을 준비하세요.
확인은 세 단계로 나누면 좋습니다. 첫째, 테스트 기기만 VPN 정책에 포함했을 때 해당 기기의 외부 출구 주소가 예상 경로로 바뀌는지 확인합니다. 둘째, 정책에서 제외한 다른 기기는 일반 경로를 유지하는지 확인합니다. 셋째, 특정 도메인이나 애플리케이션을 기준으로 추가한 규칙이 실제로 적용되는지 확인합니다. 한 기기에서 모든 테스트를 동시에 하면 결과를 해석하기 어려우므로 대상과 제외 대상을 나누는 것이 좋습니다.
| 확인 대상 | 확인 방법 | 문제가 있을 때 의심할 부분 |
|---|---|---|
| VPN 인터페이스 | OpenWrt 네트워크 상태와 클라이언트 로그 확인 | 인증, 프로토콜 호환성, 터널 주소, 시간 설정 |
| 기기별 정책 | 대상 기기와 제외 기기의 출구 경로 비교 | 고정 임대 주소, 정책 우선순위, 기본 경로 |
| 도메인 규칙 | 코어 로그와 DNS 질의 기록 확인 | DNS 우회, 캐시, CDN 주소 변경, 규칙 형식 |
| IPv6 | IPv4와 IPv6 연결을 각각 확인 | IPv6 기본 경로, IPv6 DNS, 터널의 IPv6 지원 여부 |
| 속도와 안정성 | 실제 사용할 앱과 웹서비스로 반복 확인 | MTU, UDP 제한, CPU 사용량, 노드와 전송 방식 |
SSH 접속이 가능하다면 OpenWrt의 라우팅과 로그를 직접 확인할 수 있습니다. 명령어 이름과 출력 형식은 펌웨어와 방화벽 버전에 따라 달라질 수 있지만, 기본 방향은 현재 라우팅 테이블, 정책 규칙, 방화벽 로그, VPN 프로세스 로그를 각각 확인하는 것입니다.
ip route
ip rule
logread | tail
uci show firewall > /tmp/firewall-backup.uci
sysupgrade -b /tmp/openwrt-backup.tar.gz위 명령은 설정을 변경하기 전에 참고용 백업을 만들 때 사용할 수 있습니다. 백업 파일을 공유기 내부에만 두면 저장장치 문제나 재설정 시 함께 사라질 수 있으므로 안전한 관리 장치로 복사하세요. 명령어 결과에 예상하지 않은 두 개의 기본 경로가 보이거나, 정책 규칙이 전혀 생성되지 않았다면 인터넷 연결을 반복해서 끊기보다 해당 정책 서비스를 먼저 중지하고 구성을 다시 검토하는 편이 안전합니다.
자주 발생하는 오류와 복구 순서
가장 흔한 오류는 VPN은 연결되었지만 대상 기기의 인터넷이 끊기는 경우입니다. 이때는 먼저 VPN 노드 자체가 정상인지 확인한 뒤, 정책을 잠시 비활성화하고 일반 WAN 연결이 복구되는지 확인합니다. WAN까지 끊긴다면 기본 경로 또는 DNS가 잘못된 가능성이 있습니다. 일반 연결은 되지만 정책 대상만 접속되지 않는다면 VPN 인터페이스의 게이트웨이, AllowedIPs, 방화벽 영역, NAT 설정을 살펴보세요.
특정 도메인만 접속되지 않는 경우에는 도메인 규칙보다 먼저 DNS 결과를 확인해야 합니다. 도메인이 여러 IP로 해석되는데 일부 주소만 정책 집합에 들어갔거나, 캐시된 이전 주소가 남아 있을 수 있습니다. CDN이나 지역별 응답을 사용하는 서비스는 IP 목록을 수동으로 고정하는 방식이 유지되지 않을 수 있으므로, 도메인 기반 규칙을 지원하는 코어와 DNS 연동을 검토하세요.
연결은 되지만 일부 앱만 일반 경로를 사용하는 경우도 있습니다. 해당 앱이 시스템 프록시를 무시하거나, QUIC·UDP를 별도로 사용하거나, 자체 DNS를 실행하는지 확인합니다. 시스템 프록시 방식과 TUN 또는 TProxy 방식은 제어 범위가 다릅니다. 앱 전체의 트래픽을 공유기에서 다루려면 단순한 HTTP 프록시만으로는 부족할 수 있으며, 사용하는 코어와 방화벽 모드가 해당 트래픽을 지원하는지 확인해야 합니다.
- ✅ 문제가 생기면 먼저 새로 추가한 마지막 규칙 하나를 되돌리세요.
- ✅ VPN 정책을 끈 뒤 WAN 인터넷이 복구되는지 분리해서 테스트하세요.
- ✅ 로그에서 인증 실패, DNS 오류, 라우팅 누락, 방화벽 차단을 구분하세요.
- ✅ 복구가 어려우면 백업 설정을 기준으로 최소 구성부터 다시 적용하세요.
- ❌ 연결이 불안정한 상태에서 노드, DNS, MTU, IPv6 설정을 한꺼번에 바꾸지 마세요.
관리 페이지에 접속할 수 없게 되었다면 먼저 유선 LAN으로 접속을 시도하고, 다른 기기에서 관리자 주소가 열리는지 확인합니다. 무선만 끊긴 것인지 공유기 전체 라우팅이 망가진 것인지 구분해야 합니다. 설정 백업이 있다면 복원 전에 현재 상태를 별도로 보관하고, 복원 후에는 VPN 서비스와 정책 라우팅을 동시에 시작하지 말고 하나씩 활성화하세요. 복구가 끝난 뒤에는 기기별 정책 하나만 남겨 정상 동작을 확인한 다음 목적지별 규칙을 점진적으로 추가합니다.
안정적인 운영을 위한 최종 점검
OpenWrt의 분할 터널링은 한 번 설정하고 끝나는 기능이 아닙니다. 공유기 펌웨어, 프록시 코어, 구독 설정, 목적지의 DNS 응답이 바뀌면 같은 규칙도 다른 결과를 낼 수 있습니다. 따라서 설정 이름에 대상 기기와 목적지를 명확히 적고, 기본 경로가 WAN인지 VPN인지 기록해 두세요. 규칙이 많아질수록 “예외 규칙”과 “최종 기본 규칙”을 구분해 두는 것이 중요합니다.
운영 중에는 VPN 노드가 바뀌었을 때 출구 주소와 DNS 경로를 다시 확인하고, 구독 업데이트 후에는 기존 정책 그룹 이름이 유지되는지 살펴보세요. 노드 목록이 갱신되면서 정책이 참조하던 이름이 사라지면 코어가 자동으로 DIRECT를 선택하거나 연결을 거부할 수 있습니다. 또한 공유기의 CPU와 메모리 사용량이 높아지면 모든 기기의 연결이 느려질 수 있으므로, 필요하지 않은 로그와 중복 코어를 정리하고 암호화 방식과 전송 유형을 환경에 맞게 선택하세요.
가정이나 소규모 사무실에서는 기기별 분할을 기본값으로 두고, 목적지별 규칙은 꼭 필요한 서비스에만 적용하는 구성이 관리하기 쉽습니다. 업무용 기기, 스마트 TV, 게임 기기처럼 사용 목적이 명확한 장치는 고정 주소와 별도 정책을 조합하면 문제 범위를 좁힐 수 있습니다. 반면 모든 기기에 복잡한 도메인 목록을 적용하면 DNS 캐시와 규칙 업데이트 때문에 원인을 찾기 어려워질 수 있습니다.
정리하면, 먼저 OpenWrt에서 사용할 터널 또는 프록시 코어를 확정하고, 테스트 기기의 주소를 고정한 뒤, 기기별 정책으로 기본 동작을 확인해야 합니다. 이후 목적지별 예외와 DNS 정책을 추가하고, IPv4·IPv6·UDP를 실제 애플리케이션으로 검증합니다. 백업과 복구 방법까지 준비해 두면 설정을 확장하더라도 전체 네트워크를 장시간 중단하지 않고 문제를 되돌릴 수 있습니다.