라우터·보조 라우터에 V2Ray 코어 설치하기: 하드웨어, 투명 프록시, DNS 분할

1. 하드웨어 선택: 아키텍처를 확인하고 사용 가능한 메모리를 계산하세요

V2Ray는 프로젝트와 도구 생태계에서 널리 쓰이는 이름입니다. 실제 배포 시에는 V2Fly의 v2ray-core와 Xray-core 중 어떤 코어를 실행할지 확인해야 합니다. v2rayN은 데스크톱 GUI 클라이언트이며, v2rayNG와 v2flyNG는 안드로이드 클라이언트입니다. 라우터에서는 코어를 직접 실행하므로 GUI 클라이언트를 설치할 필요가 없으며, 클라이언트 설치 파일을 라우터용 바이너리로 사용할 수도 없습니다.

CPU 아키텍처에 따라 프로그램 실행 가능 여부가 달라집니다. 흔히 볼 수 있는 기기는 x86_64, aarch64, 32비트 ARM, MIPS 기반이며, MIPS는 엔디언도 확인해야 합니다. CPU가 64비트를 지원한다고 해서 펌웨어의 사용자 공간도 64비트라는 뜻은 아닙니다. 설치 파일은 펌웨어 패키지 저장소의 아키텍처와 코어 릴리스 안내를 기준으로 선택하세요. 배포 전에 기기 터미널에서 다음 정보를 확인하세요.

uname -m
cat /etc/openwrt_release
free -m
df -h

/etc/openwrt_release는 OpenWrt에서만 사용할 수 있습니다. 일반 Linux에서는 /etc/os-release를 확인하세요. 총 메모리 용량만 보지 말고 사용 가능한 메모리와 쓰기 가능한 저장 공간을 확인하는 것이 중요합니다. 규칙 데이터, DNS 캐시, 연결 수, 로그가 늘면 자원 사용량도 증가합니다. 코어가 시작되더라도 연결이 많을 때 안정적으로 작동한다는 보장은 없습니다.

• CPU: 코어 수가 같다고 프록시 처리량까지 같지는 않습니다. 단일 코어 부하가 한계에 가까운지 살펴보고 프록시 트래픽과 일반 전달 트래픽을 구분하세요.
• 저장 공간: 코어, geosite/geoip 데이터, 업데이트 임시 파일을 모두 저장할 수 있는지 확인하세요. 용량이 작은 플래시 메모리에 디버그 로그를 계속 기록하지 마세요.
• 네트워크 인터페이스: 단일 포트 기기로도 보조 라우터를 구성할 수 있지만 라우팅 설계를 더 세심하게 해야 합니다. 포트가 두 개면 입구와 출구를 나누기 쉽지만, 잘못된 정책 라우팅까지 자동으로 해결되지는 않습니다.
• 시스템: 펌웨어에서 필요한 커널 모듈과 패키지를 제공하는지 확인하세요. 사용자 공간 프로그램이 있다고 해서 시스템에서 TPROXY나 TUN을 지원하는 것은 아닙니다.

2. 코어 선택: 노드 설정과 펌웨어 통합 상태를 기준으로

노드에 필요한 기능부터 확인한 다음 펌웨어에서 안정적으로 관리할 수 있는 코어를 선택하세요. 프로토콜, 보안 계층, 전송 방식은 서로 다른 요소입니다. VLESS 자체에는 콘텐츠 암호화가 포함되지 않으며, REALITY는 관련 보안 메커니즘이고 WebSocket은 전송 방식입니다. 구독에 “V2Ray”라고 적혀 있다는 이유만으로 두 코어의 모든 설정 항목을 서로 바꿔 쓸 수 있다고 판단해서는 안 됩니다.

구독은 보통 노드 정보를 제공할 뿐, 바로 실행할 수 있는 완성된 게이트웨이 설정은 아닙니다. 공유 링크나 Base64 형식의 노드 목록은 호환되는 관리 도구로 파싱한 뒤 인바운드, 아웃바운드, 라우팅, DNS 설정으로 만들어야 합니다. 코어를 직접 실행하려면 해당 형식의 설정 파일을 준비해야 합니다. 서비스 이름, 파일 경로, 업데이트 방식은 펌웨어 패키지마다 다르므로 임의로 추측하지 마세요.

3. 메인 라우터와 보조 라우터: 기기 이름보다 트래픽 경로가 중요합니다

메인 라우터는 보통 인터넷 연결, DHCP, NAT, 방화벽을 담당합니다. 여기에 프록시 코어를 함께 실행하면 통합된 전달 경로에서 트래픽을 처리할 수 있습니다. 보조 라우터는 대개 인터넷 연결을 직접 담당하지 않으므로 대상 기기의 트래픽이 실제로 보조 라우터를 통과하도록 설정해야 합니다. 한 기기를 같은 LAN에 연결하는 것만으로 다른 기기의 트래픽까지 자동으로 전달되지는 않습니다.

예를 들어 메인 라우터가 192.168.10.1, 보조 라우터가 192.168.10.2, 테스트 기기가 192.168.10.100이라고 가정해 보겠습니다. 테스트 기기의 기본 게이트웨이는 192.168.10.2로, 보조 라우터의 기본 출구는 192.168.10.1로 설정합니다. IPv4 구성 예시일 뿐이므로 실제 네트워크 대역에 맞는 주소를 사용해야 합니다. 보조 라우터 주소는 중복 할당될 수 있는 DHCP 주소 풀에 포함하지 마세요.

1. 보조 라우터에 고정 IP 주소를 설정하거나 DHCP 고정 임대를 지정해 재부팅 후에도 주소가 바뀌지 않도록 하세요.
2. 테스트 기기의 게이트웨이를 직접 설정하고, DNS는 쿼리를 처리할 로컬 리졸버를 가리키도록 지정하세요.
3. 보조 라우터에서 IP 포워딩이 활성화되어 있는지, 방화벽에서 필요한 전달을 허용하는지, 응답 트래픽이 올바르게 처리되는지 확인하세요.
4. 일반 연결과 프록시 연결을 검증한 뒤 DHCP에서 배포하는 게이트웨이 옵션을 변경하세요. 주소 할당을 두고 경쟁하는 DHCP 서버를 동시에 활성화하지 마세요.

4. 투명 프록시 방식: REDIRECT, TPROXY, TUN 비교

투명 프록시는 게이트웨이가 연결을 가로채는 방식이지, 노드 프로토콜의 한 종류가 아닙니다. 명시적 SOCKS 프록시는 앱이 프록시 포트에 직접 연결하며, 투명 프록시는 방화벽, 정책 라우팅 또는 가상 네트워크 인터페이스를 통해 트래픽을 코어로 전달합니다. 두 문제를 한꺼번에 진단하지 않도록 먼저 명시적 프록시 연결을 확인한 다음 투명 프록시를 설정하세요.

TPROXY를 예로 들면 방화벽에서 선택한 트래픽에 먼저 마크를 지정한 다음 투명 인바운드로 전달해야 합니다. 정책 라우팅은 마크가 붙은 패킷을 로컬 처리 경로로 보내는 역할을 합니다. 이 과정 중 하나라도 빠지면 규칙 카운터는 증가하는데 연결 로그는 남지 않을 수 있습니다. 투명 인바운드 포트 예시로 12345를 사용할 수 있습니다. 앱 테스트용 10808과는 역할이 다르므로 포트 번호만 바꿔서는 트래픽을 가로챌 수 없습니다.

• 먼저 제외할 대상: 라우터 관리 주소, 필요한 LAN 대상, 노드 서버 주소, 코어 자체에서 시작하는 연결을 제외해 프록시 루프를 방지하세요.
• 체인 구분: 종단 기기에서 전달되는 트래픽과 라우터 자체 트래픽은 진입 경로가 다릅니다. 전자의 가로채기가 성공해도 구독 업데이트까지 같은 경로를 이용한다는 뜻은 아닙니다.
• 백엔드 확인: OpenWrt 22.03부터는 firewall4와 nftables 조합이 기본으로 널리 사용됩니다. 이전 펌웨어는 firewall3와 iptables를 사용할 수 있으므로 서로 다른 규칙을 무작정 섞지 마세요.
• 관리 경로 확보: 규칙을 반복 적용해도 중복으로 쌓이지 않도록 하고, 명확한 해제 방법을 마련하세요. 원격으로 설정을 변경하기 전에는 다른 관리 연결을 유지하세요.

UDP 가로채기에 성공해도 모든 UDP 앱이 작동하는 것은 아닙니다. 노드의 아웃바운드, 서버, 중간 네트워크에서도 해당 트래픽을 지원해야 합니다. 웹은 열리지만 음성 통화나 게임이 실패한다면 UDP 로그와 규칙을 별도로 점검하세요. 하드웨어 트래픽 오프로딩 때문에 소프트웨어 규칙에서 트래픽이 보이지 않을 수도 있습니다. 진단할 때는 오프로딩을 잠시 끄고 규칙 카운터와 연결 동작을 비교해 보세요.

5. DNS 분할: DNS 질의 경로와 연결 경로를 함께 설정하세요

DNS 분할에는 최소 세 가지 경로가 관여합니다. 종단 기기가 누구에게 질의를 보내는지, 로컬 리졸버가 어떤 업스트림을 선택하는지, 리졸버가 업스트림에 접속할 때 어떤 네트워크 경로를 사용하는지 확인해야 합니다. 보조 라우터의 DNS 주소를 지정하는 것만으로는 첫 번째 단계만 해결됩니다. 업스트림 질의가 적절하지 않은 경로로 나가면 잘못된 응답이나 반복적인 시간 초과가 발생할 수 있습니다.

일반적인 구성에서는 라우터의 dnsmasq를 유지해 DHCP, 로컬 네트워크 이름, 캐시를 처리합니다. 규칙에 따라 일부 질의를 별도의 리졸버 인바운드나 코어 DNS로 전달할 수 있습니다. 코어의 dns 설정만으로 LAN에 DNS 서비스 포트가 자동으로 열리지는 않으므로 실제 인바운드나 DNS 전달 방식을 따로 구성해야 합니다.

1. 업스트림 경로를 하나로 정하세요: 종단 기기 → dnsmasq → 지정된 리졸버 인바운드 → 업스트림. 같은 유형의 질의를 dnsmasq와 코어 DNS가 서로에게 전달하도록 구성하지 마세요.
2. 로컬 이름 해석을 유지하세요: LAN 호스트 이름과 내부 도메인은 해당 레코드를 알고 있는 리졸버에서 처리해야 합니다. 모든 질의를 공용 업스트림으로 보내지 마세요.
3. 노드 도메인 조회 경로를 마련하세요: 프록시 연결을 만들기 전에 노드 서버 도메인을 조회해야 할 수 있습니다. 아직 연결되지 않은 프록시에 이 DNS 경로가 의존해서는 안 됩니다.
4. IPv6를 확인하세요: DHCPv6, 라우터 광고, AAAA 질의가 어디로 향하는지 살펴보고 IPv6 연결 정책과 DNS 응답이 일치하도록 설정하세요.

dnsmasq가 LAN에서 53 포트를 사용한다고 가정하면, 다른 리졸버 인바운드는 지원 여부를 확인한 뒤 127.0.0.1:5353에 바인딩하고 dnsmasq가 지정된 질의를 전달하도록 설정할 수 있습니다. 5353은 mDNS에도 자주 사용되므로 사용 전에 포트 점유 여부를 확인하세요. 두 서비스가 동일한 주소와 포트에 바인딩되면 안 됩니다. 외부에 공개되는 인바운드는 WAN 쪽에서 접근할 수 없도록 방화벽으로 제한해야 합니다.

도메인 라우팅과 IP 라우팅도 구분해야 합니다. 투명 연결이 코어에 전달될 때 대상 IP만 보일 수 있습니다. 스니핑은 지원되는 프로토콜에서 도메인 정보를 제공할 수 있지만 모든 트래픽에서 작동하는 것은 아닙니다. geosite는 도메인 분류에, geoip는 IP 분류에 사용되며 둘 다 해당 데이터 파일이 필요합니다. 라우팅 규칙은 일반적으로 순서대로 적용됩니다. domainStrategy는 라우팅 단계에서 IP 규칙에 도메인 조회를 적용할지 결정하며, 종단 기기의 DNS 설정을 대신하지는 않습니다.

6. 배포 검증: 기기 한 대부터 시작해 적용 범위를 넓히세요

설정 검증에서는 코어 실행, 노드 연결, 종단 기기 트래픽 가로채기, DNS 응답 확인을 각각 따로 점검해야 합니다. 한 번의 작업에서 펌웨어를 업그레이드하고 코어를 교체하고 게이트웨이를 바꾸면서 새 규칙까지 가져오지 마세요. 문제가 생겼을 때 로그만으로 원인을 특정하기 어려워집니다.

1. 백업: 네트워크, 방화벽, DHCP, 코어 설정을 저장하고 메인 라우터의 관리 주소와 일반 연결로 복구하는 방법을 기록하세요.
2. 설정 검사: 아래 명령으로 Xray 설정을 검사할 수 있습니다. V2Fly의 명령줄 옵션은 현재 버전의 도움말을 확인하고, Xray 명령을 그대로 적용하지 마세요.
3. 명시적 연결 테스트: 테스트 앱 하나만 SOCKS 인바운드에 연결해 노드 연결, 시간 설정, 인증서 설정이 올바른지 확인하세요.
4. 투명 프록시 테스트: 테스트 기기만 가로채도록 설정하고 방화벽 카운터, 코어 접근 로그, 실제 외부 출구를 확인하세요. TCP와 필요한 UDP 앱도 각각 테스트해야 합니다.
5. 지속적인 상태 확인: 유휴 상태, 다운로드 중, 여러 기기에서 접속할 때의 사용 가능 메모리, CPU, 온도, 오류 로그를 확인한 뒤 적용 범위를 넓히세요.

# 설정 파일 경로는 이 문서의 예시입니다. 실제 설치 위치에 맞게 조정하세요
xray run -test -config /etc/xray/config.json

# 다음 명령은 관련 도구가 설치된 Linux 환경에서 사용합니다
ip route
ip -6 route
ip rule
ss -lnptu
nft list ruleset

# 조회 예시: DNS를 실제로 처리하는 기기의 주소로 바꾸세요
nslookup example.com 192.168.10.2

일부 경량 펌웨어에는 ss 같은 진단 도구를 별도로 설치해야 합니다. 명령을 찾을 수 없다고 해서 서비스에 문제가 있다는 뜻은 아닙니다. 로그를 공유하기 전에 구독 주소, 인증 정보, 노드 접속 정보를 숨기세요. 문제를 찾기 위해 상세 로그를 잠시 켰다면 진단 후 로그 수준을 낮추세요. 디스크에 계속 기록되거나 접속 기록이 노출되는 일을 막을 수 있습니다.