이 글은 데스크톱이나 Android 클라이언트를 사용할 줄 알고, LAN 기기들이 프록시 출구를 함께 이용하도록 설정하려는 사용자를 위한 안내입니다. 테스트 기기 한 대로 우회 라우터 게이트웨이를 확인한 뒤 코어, 투명 프록시 인바운드, DNS, 라우팅 규칙을 차례로 점검합니다. 내용을 읽고 나면 코어를 메인 라우터와 우회 라우터 중 어디에 설치할지 판단하고, OpenWrt 네트워크 계층 설정과 Xray 또는 V2Fly 코어 설정을 구분할 수 있습니다. 여기서는 배포 절차와 확인 방법을 다루며, 기기 환경에 상관없이 그대로 적용할 수 있는 방화벽 스크립트 전체를 제공하지는 않습니다.
1. 메인 라우터와 우회 라우터: 먼저 트래픽 경로를 확인하세요
투명 프록시를 사용하려면 트래픽이 실제로 코어가 실행되는 기기를 통과해야 합니다. “같은 LAN에 OpenWrt 기기가 있다”는 것만으로 다른 기기들이 자동으로 해당 기기를 사용하는 것은 아닙니다. 메인 라우터가 기본 게이트웨이라면 포워딩 경로에서 트래픽을 가로챌 수 있습니다. 우회 라우터를 스위치에만 연결한 경우에는 보통 단말의 기본 게이트웨이를 바꾸거나, 메인 라우터의 정책 라우팅으로 지정된 트래픽을 우회 라우터로 보내야 합니다.
우회 라우터를 단일 기기로 시험 적용
권장기존 메인 라우터의 인터넷 연결, 무선 기능, DHCP는 그대로 두고 테스트 컴퓨터 한 대에만 우회 라우터 게이트웨이를 지정합니다. 문제가 생겨도 영향 범위가 작고, 해당 컴퓨터의 네트워크 설정만 되돌리면 됩니다.
적합한 경우: 안정적인 네트워크가 이미 있고 투명 프록시를 처음 배포하는 경우
메인 라우터에서 코어 직접 실행
OpenWrt가 게이트웨이와 프록시 포워딩을 함께 담당하므로 경로가 비교적 단순합니다. 다만 코어 장애, 방화벽 변경, 리소스 부족이 LAN 전체에 영향을 줄 수 있습니다.
적합한 경우: OpenWrt에 익숙하고 통합 게이트웨이를 관리할 수 있는 경우
메인 라우터 정책으로 우회 라우터에 전달
단말은 메인 라우터를 게이트웨이로 계속 사용하고, 메인 라우터가 기기나 네트워크 대역을 기준으로 우회 라우터에 전달합니다. 왕복 경로와 루프 제외 조건을 설계해야 하며, 기본 경로 하나만 추가해서는 안 됩니다.
적합한 경우: 기기 그룹을 중앙에서 관리해야 하고 정책 라우팅 경험이 있는 경우
LAN 포트가 하나인 우회 라우터를 연결하면 메인 라우터와 단말이 같은 서브넷에 놓이는 경우가 많습니다. 이때 목적지로 가는 패킷은 먼저 우회 라우터에 도착하지만, 응답은 메인 라우터가 단말에 직접 보낼 수 있습니다. 소스 NAT가 필요한지는 응답 경로, 상태 기반 방화벽, 연결 추적을 고려해 판단해야 합니다. NAT를 켜는 것을 만능 해결책처럼 취급해서는 안 됩니다. 같은 인터페이스를 통한 포워딩은 ICMP 리디렉션을 유발할 수도 있으므로, 단말이 예상한 게이트웨이를 우회하지 않는지 확인하세요.
2. 주소와 포트 계획: DHCP 서버 두 대가 동시에 주소를 배포하지 않도록 하세요
다음과 같은 명확한 예시 네트워크를 사용합니다. 메인 라우터는 192.168.10.1, 우회 라우터는 192.168.10.2, 테스트 컴퓨터는 192.168.10.100, 서브넷 마스크는 255.255.255.0입니다. 이 값은 이 글에서 정한 예시이며 기기의 출고 설정이 아닙니다. 사용하기 전에 주소가 사용 중이지 않은지 확인하고, 우회 라우터 주소를 DHCP 동적 할당 범위에서 제외하세요.
| 대상 | 예시 설정 | 용도 |
|---|---|---|
| 메인 라우터 | 192.168.10.1/24 | 상위 네트워크에 연결하고 기존 DHCP 서비스를 유지 |
| 우회 라우터 LAN | 192.168.10.2/24 | 관리용 고정 주소를 설정하고 상위 게이트웨이는 메인 라우터로 지정 |
| 테스트 컴퓨터 | 192.168.10.100/24 | 기본 게이트웨이와 DNS를 우회 라우터 주소로 임시 설정 |
| 기타 단말 | 기존 자동 설정 유지 | 시험 적용 중에는 기존 네트워크 경로 사용 |
포트는 실제 리스닝 설정과 일치해야 합니다. 여기서는 선택 사항인 로컬 DNS 리졸버를 1053, 투명 프록시 인바운드를 12345로 표시합니다. 코어를 설치해도 이 두 포트가 자동으로 열리지는 않습니다. dnsmasq는 보통 단말에 53번 포트 서비스를 제공하므로, 다른 프로세스가 같은 주소의 53번 포트를 동시에 점유하지 않도록 하세요.
3. Xray와 V2Fly: 프로토콜 설정에 따라 코어를 선택하세요
V2Ray는 프로젝트와 기술 생태계에서 널리 쓰이는 이름이지만, 실제 배포 시에는 어떤 코어를 사용할지 구분해야 합니다. Xray와 V2Fly는 서로 바꿔 부를 수 있는 이름이 아니며, 같은 설정 파일이 양쪽에서 그대로 작동한다고 보장할 수도 없습니다. 기존 연결에서 REALITY 또는 XTLS Vision이 필요하다면 Xray가 해당 기능을 지원하는지 확인하세요. VMess 같은 연결을 사용하는 경우에는 서버 매개변수, 전송 방식, 선택한 버전의 호환성을 확인해야 합니다.
- 데스크톱에서 연결 확인: 먼저 v2rayN에서 연결이 되는지 확인하고 프로토콜, 주소, 포트, 사용자 ID, TLS, 전송 방식 및 관련 항목을 기록하세요. 데스크톱에서 연결된다고 해서 라우터 설정까지 올바른 것은 아닙니다.
- Android 클라이언트 비교: v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트에 저장된 구독 정보와 실행 시 사용하는 코어 설정은 서로 다른 파일 형식입니다.
- 구독 형식 확인: 구독은 인코딩된 공유 링크 모음일 수도 있고 특정 클라이언트 전용 형식일 수도 있습니다. 독립 실행형 코어는 일반적으로 자체 설정 파일을 읽으며, 임의의 구독 URL을 실행 가능한 설정으로 자동 변환하지 않습니다.
- 기기 아키텍처 확인: OpenWrt 패키지 아키텍처와 프로세서 정보를 기준으로 프로그램을 선택하세요. 기기 설명에 ‘64비트’라고 쓰여 있다는 사실만으로 바이너리 실행 가능 여부를 판단할 수 없습니다. 명령어 집합과 빌드 호환성도 확인해야 합니다.
cat /etc/openwrt_release
ubus call system board
uname -m
# 해당 코어가 설치되어 있다면 버전 확인
xray version
v2ray version현재 펌웨어 버전과 아키텍처에 맞는 패키지 저장소를 우선 사용하세요. OpenWrt 22.03부터 기본 방화벽이 firewall4와 nftables로 바뀌었습니다. 이전 버전의 iptables 기반 가이드를 모든 환경에 그대로 적용할 수는 없습니다. 패키지 관리 도구도 펌웨어 버전에 따라 달라질 수 있으므로 현재 시스템에서 사용하는 도구를 먼저 확인하고, 서로 다른 배포 버전의 저장소를 섞어 쓰지 마세요.
결론: 연결을 확인한 다음 트래픽을 가로채세요
게이트웨이를 바꾸기 전에 우회 라우터의 코어에서 명시적 프록시 인바운드를 통해 연결을 한 번 테스트하세요. 그러면 노드나 설정 문제와 투명 포워딩 문제를 구분할 수 있어 프로토콜, DNS, 방화벽을 동시에 점검하는 일을 피할 수 있습니다.
4. OpenWrt 배포 절차: 네트워크, 코어, 포워딩을 나눠 설정하세요
아래 메뉴 경로는 일반적인 중국어 LuCI 인터페이스를 기준으로 설명합니다. 항목 이름은 펌웨어와 번역에 따라 다를 수 있습니다. 작업 전에 현재 설정을 저장하고, 메인 라우터에 직접 접속할 수 있는 기기를 한 대 확보하세요. 첫 시험 적용부터 LAN 전체의 DHCP 게이트웨이를 바꾸거나 원격 접속 중에 방화벽 규칙 전체를 한꺼번에 교체하지 마세요.
-
설정 백업
「시스템」→「백업/업그레이드」→「백업 생성」으로 이동해 현재 설정을 저장하세요. 메인 라우터 주소, DHCP 범위, 우회 라우터 연결 방식을 기록하고 유선으로 직접 관리 화면에 접속할 방법도 미리 준비하세요.
-
고정 주소 설정
「네트워크」→「인터페이스」→「LAN」→「편집」→「일반 설정」으로 이동해 고정 주소
192.168.10.2, 서브넷 마스크255.255.255.0, 게이트웨이192.168.10.1을 설정하세요. 관리 주소에 접속할 수 있는지 확인한 뒤 DHCP를 설정합니다. -
코어 확인
기기 아키텍처에 맞는 Xray 또는 V2Fly를 설치하고 해당 형식의 설정 파일을 작성하세요. 먼저 구문을 확인한 다음, 임시 명시적 프록시 인바운드를 실행해 연결을 테스트합니다. 이 단계에서는 전체 트래픽을 가로채지 않습니다.
-
포워딩 설정
현재 방화벽 백엔드에 맞춰 투명 프록시 인바운드, 트래픽 마크, 필요한 정책 라우팅을 구성하세요. 먼저 출발지 범위를
192.168.10.100으로 제한하고 우회 라우터 자체, 코어의 외부 연결, 관리 네트워크 대역은 제외합니다. -
테스트 기기 연결
테스트 컴퓨터의 기본 게이트웨이와 DNS를
192.168.10.2로 바꾸고 시스템 프록시를 끄세요. 데스크톱 클라이언트가 라우팅 문제를 가리지 않도록 직접 연결 주소, 프록시 대상, 도메인 이름 해석을 각각 테스트합니다. -
자동 시작 설정
테스트를 통과한 뒤 procd 서비스와 방화벽 영구 규칙을 설정하세요. 「시스템」→「시작 스크립트」에서 서비스 상태를 확인하고, 기기를 재부팅해 규칙과 프로세스가 모두 복구되는지 테스트합니다.
아래 명령은 정해 둔 설정 파일 위치를 기준으로 점검하는 예시입니다. 설치한 코어에 해당하는 명령만 실행하고, 파일 경로가 서비스 시작 매개변수와 일치하는지 확인하세요. V2Fly 예시는 v5 명령 형식입니다. 이전 버전에서는 먼저 자체 도움말을 확인하고 매개변수를 그대로 복사하지 마세요.
# Xray 설정 확인
xray run -test -config /etc/xray/config.json
# V2Fly v5 설정 확인
v2ray test -c /etc/v2ray/config.json
# OpenWrt 서비스 로그
logread설정 확인에 성공했다는 것은 파일을 읽을 수 있다는 뜻일 뿐, 원격 서버에 연결할 수 있다는 의미는 아닙니다. 실제 구동 전에는 프로세스 권한, 로그 출력, 리스닝 주소, 시스템 시간, 인증서 검증을 확인해야 합니다. 라우터가 재부팅된 직후 시간이 동기화되지 않으면 TLS 연결이 실패할 수 있으므로, 부팅 후 점검 항목에 시간 동기화도 포함하세요.
5. 투명 프록시 원리: 방화벽 가로채기와 코어 라우팅은 별개의 계층입니다
첫 번째 계층인 OpenWrt는 어떤 패킷을 코어에 전달할지 결정하고, 두 번째 계층인 코어는 들어온 연결을 직접 연결로 보낼지 프록시 출구로 보낼지 결정합니다. 투명 인바운드 없이 코어의 라우팅 규칙만 작성하면 단말 트래픽은 코어로 들어오지 않습니다. 반대로 방화벽 포워딩만 설정하고 아웃바운드를 올바르게 구성하지 않으면 프록시 연결을 완료할 수 없습니다.
| 방식 | 주요 기능 | 배포 시 주의 사항 |
|---|---|---|
| REDIRECT | 연결을 로컬 포트로 리디렉션하며 주로 TCP 가로채기에 사용 | 코어에서 원래 목적지 주소를 복원하는 방식과 맞춰야 합니다. TCP 방식을 UDP에 그대로 적용하지 마세요. |
| TPROXY | 트래픽을 로컬 리스너로 투명하게 전달하며 TCP와 UDP에 사용할 수 있습니다. | 투명 소켓 지원, 마크, 정책 라우팅, 관련 방화벽 규칙이 필요합니다. |
| 코어 라우팅 | 도메인, 목적지 주소, 포트 등을 기준으로 아웃바운드를 선택 | 규칙 순서, 도메인 정보 출처, 사용 데이터 파일에 유의하세요. |
| 아웃바운드 제외 | 코어가 시작한 연결이 다시 가로채이지 않도록 방지 | 프로세스, 마크, 목적지 주소 등의 조건을 설계하고 노드 도메인 이름 해석도 고려하세요. |
Xray를 예로 들면 투명 프록시 인바운드에 dokodemo-door를 사용하고 followRedirect 및 호환되는 socket 설정을 함께 구성할 수 있습니다. 다만 구체적인 필드는 사용 모드에 맞춰 조합해야 합니다. TPROXY는 보통 전용 라우팅 테이블을 함께 사용해 지정된 마크가 붙은 패킷을 로컬 트래픽으로 간주하고 루프백 장치로 전달합니다. 마크 값과 라우팅 테이블 번호는 로컬 환경에 맞게 정해야 하며, 기존 VPN이나 정책 라우팅, 다른 서비스에서 사용하는 값은 피해야 합니다.
- 라우터 관리 주소, LAN 목적지, 멀티캐스트, 브로드캐스트를 먼저 제외하세요. 기기 검색과 관리 트래픽까지 전부 원격 프록시로 보내지 마세요.
- 테스트 기기만 방화벽에서 가로채려면 출발지 IP로 범위를 제한하세요. 이후 명확하게 구분된 기기 그룹에 단계적으로 적용하고, 처음부터 LAN 전체에 규칙을 적용하지 마세요.
- 코어 자체의 아웃바운드 연결은 투명 프록시 인바운드를 우회해야 합니다. 그렇지 않으면 프록시 연결이 다시 프록시에 들어가는 루프가 발생합니다.
- 검증 단계에서 트래픽 오프로딩 설정을 확인하세요. 일부 고속 포워딩 경로는 후속 패킷이 예상된 처리를 우회하게 만들 수 있습니다. 먼저 오프로딩 영향을 배제한 다음 다시 활성화할지 판단하세요.
6. DNS와 IPv6: 게이트웨이가 맞아도 트래픽 분기를 우회할 수 있습니다
단말의 DNS를 우회 라우터로 지정한 뒤에는 우회 라우터가 질의를 어디로 전달하는지, 그 경로가 트래픽 분기 목표에 맞는지 확인해야 합니다. 직접 연결할 도메인은 적절한 DNS 출구를 사용하고, 프록시할 도메인의 질의는 예상한 경로로 처리하는 편이 모든 질의를 하나의 출구에 몰아넣는 것보다 문제를 찾기 쉽습니다. dnsmasq가 코어로 질의를 전달하고 코어의 DNS 조회가 다시 dnsmasq로 돌아오면 순환이 발생하므로 주의하세요.
- 리스닝 경로를 명확히 하세요. 단말은
192.168.10.2:53에 접속합니다. 별도의 로컬 DNS 서비스를 구성한다면 dnsmasq가127.0.0.1:1053으로 전달하도록 설정할 수 있습니다. 이 경우 해당 서비스가 필요한 DNS 요청을 실제로 처리할 수 있어야 하며, 일반 프록시 포트를 대신 사용할 수는 없습니다. - 포워딩 설정을 확인하세요. 「네트워크」→「DHCP/DNS」에서 DNS 포워딩과 상위 DNS 출처를 확인하고, 통신사 네트워크에서 제공하는 리졸버를 의도치 않게 계속 사용하고 있지 않은지 살펴보세요. 변경하기 전에 기존 값을 기록해 두면 쉽게 되돌릴 수 있습니다.
- 코어 DNS 설정을 구분하세요. 코어 내장 DNS를 라우팅 판단에 사용할지 여부와 LAN에서 접속할 수 있는 DNS 인바운드를 제공할지는 서로 다른 문제입니다. 설정에 DNS 항목이 있다는 이유만으로 단말의 DNS 질의를 가로채고 있다고 판단해서는 안 됩니다.
- 암호화 DNS를 확인하세요. 브라우저의 보안 DNS나 앱 자체 DNS 기능은 단말 설정을 우회할 수 있습니다. 테스트할 때는 먼저 DNS 경로를 통일한 뒤 기기 설정이나 라우팅 정책으로 처리할 방법을 정하세요.
- IPv6를 별도로 점검하세요. IPv4 게이트웨이를 우회 라우터로 바꿔도 단말이 메인 라우터의 IPv6 라우터 광고를 따라 상위 네트워크에 직접 연결할 수 있습니다. IPv6용 포워딩과 DNS 정책을 설정하거나, 문제를 분리해 확인할 수 있도록 테스트 기기에서 일시적으로 IPv6를 비활성화하세요.
FakeDNS는 합성 주소를 반환한 뒤 코어가 원래 도메인으로 복원하는 방식입니다. ‘켜기만 하면 DNS 유출이 방지되는’ 기능은 아닙니다. 주소 대역 할당, 단말 캐시, 투명 프록시 인바운드, 라우팅 판별이 함께 맞아야 합니다. 처음 배포할 때는 먼저 일반 DNS와 TCP·UDP 포워딩을 검증한 뒤 FakeDNS가 필요한지 판단하세요. 그래야 주소 매핑 문제와 게이트웨이 문제를 구분하기 쉽습니다.
7. 문제 해결과 롤백: 주소, DNS, 포워딩 순서로 확인하세요
연결에 실패하면 먼저 기본 네트워크부터 확인하고 프로토콜을 바로 바꾸지 마세요. 테스트 컴퓨터에서 우회 라우터 관리 주소에 접속할 수 있고, 우회 라우터가 메인 라우터에 도달할 수 있으며, 코어의 명시적 프록시가 작동하는지 확인하세요. 세 가지가 모두 정상일 때 투명 프록시 가로채기와 DNS를 집중적으로 점검하면 됩니다. 테스트 도구가 선택 패키지에 포함되어 있을 수도 있으므로 명령어가 없으면 설치 여부부터 확인하세요. 명령어가 없다는 이유만으로 네트워크가 고장 났다고 판단해서는 안 됩니다.
# 우회 라우터에서 주소, 경로, 정책 규칙 확인
ip addr show
ip route show
ip rule show
# firewall4를 사용하는 시스템에서 실제 규칙 확인
nft list ruleset
# nslookup이 있는 테스트 단말에서 지정 DNS 확인
nslookup example.com 192.168.10.2| 증상 | 우선 확인할 항목 | 판단 기준 |
|---|---|---|
| 관리 페이지에도 접속할 수 없음 | 주소 충돌, 케이블, 서브넷 마스크, 기기 라우팅 | 먼저 LAN 연결을 복구하세요. 프록시 프로토콜 문제는 아닙니다. |
| 명시적 프록시는 되지만 투명 모드는 실패 | 출발지 매칭, 투명 프록시 리스너, 마크, 정책 라우팅 | OpenWrt의 트래픽 가로채기 경로를 집중적으로 확인하세요. |
| DNS 응답이 시간 초과되거나 계속 실패 | 53번 포트 리스닝, 상위 DNS 연결, DNS 순환 | 단말에서 우회 라우터까지, 우회 라우터에서 상위 DNS까지 각각 테스트하세요. |
| 일부 앱만 프록시를 우회 | UDP, IPv6, 앱 자체 DNS, 게이트웨이 | 브라우저 페이지 하나만으로 모든 기기의 트래픽을 판단할 수 없습니다. |
| 재부팅 후 작동하지 않음 | procd, 자동 시작, 규칙 영구 저장, 시간 동기화 | 구독을 반복해서 다시 가져오기보다 부팅 과정을 확인하세요. |
결론: 단일 기기 롤백 경로를 유지하세요
LAN 전체에 적용하기 전에 테스트 컴퓨터의 게이트웨이와 DNS를 기존 설정으로 되돌리고 원래 네트워크가 계속 작동하는지 확인하세요. 그다음 기기를 한 대씩 우회 라우터 정책에 추가하고 변경 사항을 기록합니다. 재부팅, DNS, UDP, IPv6 점검을 모두 통과한 뒤에만 게이트웨이를 일괄 배포하세요.
우회 라우터 배포의 핵심은 코어 프로세스를 단순히 ‘실행 중’으로 만드는 데 있지 않습니다. 이해하고 검증할 수 있으며 필요할 때 되돌릴 수 있는 네트워크 경로를 구성하는 것이 중요합니다. 먼저 프로토콜 연결을 확인하고, 다음으로 트래픽이 코어에 들어오는지 확인한 뒤, 직접 연결과 프록시 트래픽이 각각 올바른 출구로 나가는지 점검하세요. 데스크톱과 Android 클라이언트는 연결 매개변수를 먼저 검증하는 데 유용합니다. OpenWrt에서는 방화벽, 게이트웨이, DNS, 서비스 실행 주기도 별도로 관리해야 합니다.