2026-10-05 · 플랫폼 배포 · 약 12분

OpenWrt 바이패스 라우터에 V2Ray 코어 직접 설치하기: 소프트웨어 라우터 구성과 투명 프록시 가이드

기기마다 클라이언트를 설치할 필요 없이 OpenWrt 바이패스 라우터에서 V2Ray 코어를 직접 실행하는 방법을 살펴봅니다. 게이트웨이·DNS 설정, 투명 프록시와 트래픽 분배 규칙을 다룹니다.

핵심 내용

바이패스 라우터는 일반 포워딩부터 확인한 뒤 코어와 투명 프록시를 연결해야 합니다. OpenWrt 관리 페이지와 SSH를 사용할 수 있는 독자를 대상으로, LAN 주소 예시를 통해 게이트웨이, DNS, 정책 라우팅과 아웃바운드 규칙의 연동 방식을 설명합니다. 읽고 나면 단일 기기에서 시험 운영하는 계획을 세우고, 설정 오류와 트래픽 가로채기 오류를 구분하며, 연결이 끊겼을 때 복구할 방법도 마련할 수 있습니다.

바이패스 라우터 구성: 게이트웨이와 DNS를 따로 확인

OpenWrt에서 V2Ray만 실행한다고 해서 LAN 기기가 자동으로 프록시를 사용하는 것은 아닙니다. 코어는 인바운드로 전달된 연결을 처리하고, 운영체제는 기기의 트래픽을 코어로 전달합니다. 투명 프록시를 사용하려면 방화벽 규칙, 정책 라우팅, 해당 포트에서의 수신 설정도 필요합니다. 세 단계 중 하나라도 빠지면 프로세스가 정상 작동해도 실제 트래픽이 처리되지 않을 수 있습니다.

이 문서에서는 단일 인터페이스 바이패스 라우터를 예로 듭니다. 메인 라우터는 192.168.10.1, OpenWrt는 192.168.10.2, 테스트 컴퓨터는 192.168.10.100이며 서브넷 마스크는 모두 255.255.255.0입니다. 예시 주소이므로 배포 전에 실제 네트워크 대역으로 바꾸고, 바이패스 라우터 주소가 DHCP 자동 할당 범위에 포함되지 않는지 확인하세요.

기기설정 예시역할
메인 라우터192.168.10.1상위 네트워크에 연결하며 초기에는 DHCP를 계속 제공합니다.
OpenWrt192.168.10.2, 상위 게이트웨이는 192.168.10.1테스트 기기의 트래픽을 전달하고 코어와 로컬 DNS 서비스를 실행합니다.
테스트 컴퓨터게이트웨이와 DNS를 모두 192.168.10.2로 설정트래픽 처리 경로를 검증하고 다른 기기는 변경하지 않습니다.
기타 기기메인 라우터가 기존 게이트웨이와 DNS를 계속 할당기존 인터넷 연결 경로를 유지해 테스트 영향을 줄입니다.

게이트웨이는 패킷의 다음 홉을, DNS는 도메인 이름의 해석 경로를 결정합니다. 둘은 같은 설정이 아닙니다. DNS만 바꾸면 일반 웹 연결은 대개 바이패스 라우터를 거치지 않습니다. 게이트웨이만 바꿔도 기기가 바이패스 라우터의 DNS 정책을 따른다고 보장할 수 없습니다. 브라우저의 보안 DNS, 자체 DNS 확인 기능을 사용하는 앱, IPv6 기본 경로가 별도의 경로를 만들 수도 있습니다.

코어 선택: 노드 설정을 기준으로 판단

OpenWrt에서 직접 실행하는 것은 데스크톱 클라이언트 UI가 아니라 코어 프로세스입니다. v2rayN은 데스크톱 설정을, v2rayNG와 v2flyNG는 Android 설정을 관리합니다. 이들 클라이언트의 메뉴를 라우터에 그대로 적용할 수는 없습니다. 서버 주소, 포트, 인증 정보, 전송 방식, TLS, 서비스 이름 등의 매개변수를 선택한 코어가 읽을 수 있는 설정으로 변환해야 합니다.

V2Fly 코어

권장

이 문서에서는 V2Fly의 V2Ray 5.x 명령줄 사용을 기준으로 설명합니다. VMess 등 호환되는 설정이 이미 있다면 해당 코어를 우선 사용해 이전 변수를 줄일 수 있습니다. 다만 실제 버전에 맞는 전송 관련 필드는 확인해야 합니다.

적합한 경우: 호환되는 설정이 있고 바이패스 라우터 연결부터 검증하려는 경우

Xray 코어

노드에서 REALITY 또는 XTLS Vision을 명시적으로 요구한다면 해당 기능을 지원하는 Xray 버전을 사용해야 합니다. 실행 파일 이름을 v2ray로 바꾸고 설정 필드와 명령줄 옵션이 모두 호환된다고 가정해서는 안 됩니다.

적합한 경우: 노드가 Xray 전용 설정을 명시적으로 요구하는 경우

결론: 노드 설정 전체를 먼저 확인

프로토콜, 전송 방식, 보안 계층, 코어 버전을 설정 기록에 정리한 뒤 배포할 코어를 결정하세요. “VLESS” 또는 “VMess”라는 이름만으로 노드 설정 전체의 호환성을 판단할 수는 없습니다.

설치 전에 프로세서 아키텍처, 저장 공간, OpenWrt 패키지 저장소도 확인해야 합니다. uname -m으로 실행 중인 아키텍처를 확인할 수 있지만, 패키지는 배포판 ABI와 종속성에도 영향을 받습니다. 다른 OpenWrt 브랜치의 패키지 저장소를 섞어 쓰지 마세요. 구독 링크가 코어용 설정 파일을 뜻하는 것도 아닙니다. 구독은 해당 형식을 지원하는 도구로 파싱해야 하며, 업데이트 후에는 실행 설정을 교체하기 전에 먼저 테스트하세요.

배포 순서: 포워딩부터 확인하고 기기 한 대만 연결

전체 네트워크의 DHCP, DNS, 방화벽 설정을 한꺼번에 바꾸지 마세요. 먼저 설정을 백업한 다음 테스트 컴퓨터 한 대만 변경하는 방법을 권장합니다. 아래 메뉴는 일반적인 LuCI 화면을 기준으로 합니다. 번역이나 버전에 따라 항목이 다를 수 있으니 버튼 위치만 보고 조작하지 말고 화면의 필드명을 확인하세요.

  1. 설정 백업

    「시스템」→「백업/업그레이드」→「백업 생성」으로 이동해 현재 설정을 저장하세요. 컴퓨터의 기존 게이트웨이와 DNS를 기록하고, OpenWrt 관리 주소에 직접 접속하는 방법도 유지하세요.

  2. 고정 주소

    「네트워크」→「인터페이스」→「LAN」→「편집」으로 이동해 고정 주소가 예시와 같이 192.168.10.2/24이고 상위 IPv4 게이트웨이가 192.168.10.1인지 확인하세요. DHCP 서버가 두 개 실행 중인지 점검해 주소 할당 충돌을 방지하세요.

  3. 포워딩 확인

    투명 프록시는 아직 활성화하지 말고 테스트 컴퓨터의 게이트웨이만 바이패스 라우터로 바꾸세요. 「네트워크」→「방화벽」에서 관련 영역의 포워딩 정책과 필요한 소스 주소 변환을 확인한 뒤 일반 직접 연결이 되는지 점검하세요.

  4. 코어 테스트

    설정을 모두 준비한 뒤 v2ray test -c /etc/v2ray/config.json을 실행하세요. 통과하면 먼저 포그라운드에서 실행해 로그를 확인한 다음, 설정된 procd 서비스에 맡기세요. 이전 버전은 명령이 다를 수 있으므로 먼저 v2ray help를 확인하세요.

  5. 트래픽 처리 범위 제한

    테스트 컴퓨터 192.168.10.100의 트래픽만 대상으로 투명 인바운드, 정책 라우팅, 방화벽을 설정하세요. 직접 연결, 프록시, DNS가 예상대로 작동하는지 확인한 후에 DHCP를 통해 바이패스 라우터 게이트웨이를 할당할지 검토하세요.

# 다음은 V2Fly V2Ray 5.x의 설정 검사 및 포그라운드 실행 예시입니다
v2ray version
v2ray test -c /etc/v2ray/config.json
v2ray run -c /etc/v2ray/config.json

# 다음 명령은 다른 SSH 세션에서 시스템 상태를 확인합니다
ip -4 route show
ip -4 rule show
ss -lntup
logread -e v2ray

투명 프록시: 인바운드, 마크, 정책 라우팅

투명 프록시는 시스템 프록시 포트를 외부에 공개하는 방식이 아닙니다. 일반적으로 REDIRECT는 TCP 리디렉션에 주로 사용하고, TPROXY는 TCP와 UDP를 처리할 수 있지만 커널 모듈, 투명 소켓 지원, 패킷 마크, 정책 라우팅이 함께 작동해야 합니다. 인바운드 설정은 방화벽에서 사용하는 방식과 일치해야 합니다.

OpenWrt 22.03부터 기본 방화벽 체계는 firewall4와 nftables로 전환되었습니다. 이전 튜토리얼의 iptables 명령을 현재 설정 기준으로 그대로 사용하지 마세요. 시스템에서 실제로 사용하는 방화벽을 확인하고 TPROXY 지원이 활성화되어 있는지 점검하세요. 명령이 성공적으로 실행됐더라도 규칙이 대상 트래픽에 적용된다는 뜻은 아닙니다.

12345
투명 인바운드 포트 예시
0x1
정책 라우팅 마크 예시
100
별도 라우팅 테이블 번호 예시

위 값은 계획을 위한 예시이며 실측값이나 모든 시스템에 적용되는 고정 요구 사항이 아닙니다. TPROXY 규칙은 지정된 연결을 12345 인바운드로 전달하고 마크를 설정합니다. 해당 ip rule은 마크가 지정된 패킷을 별도 라우팅 테이블로 보내며, 그 테이블에는 로컬 전달 경로가 있어야 합니다. 마크 값, 마스크, 라우팅 테이블 번호를 함께 확인하고 기존 정책과 충돌하지 않도록 하세요.

확인 단계확인할 내용누락 시 증상
트래픽 유입소스 주소, LAN 인터페이스, TCP/UDP 적용 범위코어에 연결 기록이 없거나 다른 기기의 트래픽까지 잘못 가로챕니다.
제외 규칙LAN, 관리 주소, 브로드캐스트·멀티캐스트, 노드 서버 주소관리 페이지에 접속할 수 없거나 LAN 서비스가 비정상 작동하고 프록시 루프가 발생합니다.
투명 인바운드수신 주소와 포트, 원래 목적지 확인 기능, TPROXY 소켓 옵션트래픽이 기기에 도달하지만 이를 처리할 프로세스가 없습니다.
정책 라우팅패킷 마크, 규칙 우선순위, 로컬 전달 경로패킷이 계속 포워딩되거나 폐기되어 인바운드에 요청이 도달하지 않습니다.
코어 아웃바운드서버 설정, DNS, 직접 연결·프록시 규칙의 순서인바운드 기록은 있지만 아웃바운드 연결이 실패합니다.

처음에는 LAN에서 들어오는 트래픽만 가로채고 라우터 자체의 OUTPUT 트래픽은 건드리지 마세요. 코어가 원격 서버에 연결하면 새로운 로컬 연결이 생깁니다. 이 연결이 다시 투명 인바운드로 전달되면 루프가 발생합니다. 이후 라우터 자체의 트래픽을 처리해야 한다면 별도의 아웃바운드 마크나 프로세스 제외 규칙을 설계하고, 노드 도메인을 해석한 뒤 주소가 바뀌는 경우도 처리해야 합니다.

DNS와 트래픽 분배: 이름 해석 경로를 파악할 수 있어야 합니다

DNS는 별도 서비스로 계획하는 것이 좋습니다. 단말이 바이패스 라우터의 53 포트에 질의하면 dnsmasq 같은 로컬 DNS 서비스가 적절한 상위 DNS 서버로 전달합니다. V2Ray 설정의 DNS 모듈이 LAN에 공개되는 DNS 서비스를 자동으로 제공하는 것은 아닙니다. 수신 또는 포워딩 경로를 따로 구성해야 합니다.

점검하기 쉬운 구성으로는 로컬 DNS 서비스가 LAN의 53 포트에서 수신하고, 지정된 질의를 이미 실행 중인 로컬 127.0.0.1:1053 해석 서비스로 전달하는 방법이 있습니다. 포트는 예시이므로 실제 서비스가 해당 포트에서 수신하는지 확인하세요. 하위 해석 서비스가 질의를 다시 192.168.10.2:53으로 보내면 DNS 포워딩 루프가 생깁니다.

# nslookup이 설치된 테스트 컴퓨터에서 실행
nslookup example.com 192.168.10.2

# OpenWrt에서 수신 포트와 정책을 확인
ss -lnup
ip -6 route show
nft list ruleset

결론: 속도로 경로를 추측하지 말고 로그로 확인하세요

직접 연결로 명확히 설정한 대상과 프록시로 명확히 설정한 대상을 각각 테스트하고 DNS 로그, 규칙 카운터, 코어 아웃바운드 태그를 비교하세요. 웹페이지가 열리는 것만으로 연결이 완료됐다는 점은 확인할 수 있지만, 예상한 아웃바운드 경로를 사용했다는 뜻은 아닙니다.

투명 프록시로 가로챈 트래픽에는 대상 IP만 포함될 수 있습니다. 도메인에 따라 분기한다면 도메인 정보를 어디서 얻는지 파악해야 합니다. 코어의 프로토콜 스니핑은 일부 프로토콜의 정보만 확인할 수 있으며 모든 앱에서 도메인을 복원할 수 있는 것은 아닙니다. DNS 응답 주소와 도메인 규칙, 실제 연결 대상이 일치해야 합니다. 관련 설정은 DNS 설정 안내에서 확인할 수 있지만, 데스크톱 클라이언트의 설정 항목을 OpenWrt 방화벽 규칙으로 그대로 간주해서는 안 됩니다.

자주 발생하는 문제: 연결 경로를 단계별로 점검

게이트웨이를 바꾼 뒤 인터넷이 전혀 되지 않으면 무엇부터 확인해야 하나요?

먼저 테스트 컴퓨터의 게이트웨이를 메인 라우터로 되돌려 상위 네트워크가 정상인지 확인하세요. 그런 다음 투명 프록시를 끄고 바이패스 라우터의 일반 포워딩만 테스트합니다. LAN 포워딩 정책, 상위 기본 경로, 응답 경로를 확인하고 노드를 먼저 바꾸지는 마세요.

코어가 실행 중인데 왜 연결 기록이 없나요?

컴퓨터의 실제 게이트웨이가 192.168.10.2인지 확인한 뒤 nftables 규칙 카운터를 살펴보세요. 카운터는 증가하지만 인바운드 기록이 없다면 12345 수신 설정과 마크에서 라우팅 테이블로 이어지는 매핑을 확인하고, 브라우저가 명시적 프록시를 계속 사용하는지도 점검하세요.

IP 주소로는 연결되는데 도메인 이름은 계속 시간 초과되나요?

nslookup example.com 192.168.10.2를 실행하세요. 53 포트가 수신 중인지, LAN에서 로컬 기기로 들어오는 DNS 요청이 허용되는지, 상위 DNS 서버에 연결할 수 있는지 확인하세요. 1053으로 전달한다면 해당 포트에서 실제 서비스가 실행 중인지도 확인하세요.

웹은 되는데 게임이나 일부 앱은 연결되지 않나요?

TCP 리디렉션만 설정했는지, 노드와 아웃바운드가 필요한 UDP를 지원하는지 확인하세요. IPv6 기본 경로와 관련 규칙도 점검해야 합니다. 트래픽 처리 누락을 감추려고 특정 프로토콜을 계속 차단하지 말고 앱이 실제로 사용하는 전송 방식부터 확인하세요.

방화벽을 재시작한 뒤 프록시가 작동하지 않으면 어떻게 하나요?

재시작 전후의 nft list ruleset과 ip rule show 결과를 비교하세요. 사용자 지정 규칙, 정책 라우팅, 코어 서비스 모두 영구 설정과 시작 순서를 마련해야 합니다. 동일한 마크를 중복으로 추가하는 다른 규칙이 없는지도 확인하세요.

로그를 공유할 때는 시간, 인바운드 태그, 아웃바운드 태그, 오류 유형만 남기면 됩니다. 시간 초과는 서버 연결 불가, DNS 확인 실패, 응답 경로 이상 때문에 발생할 수 있습니다. 포트 충돌은 ss -lntup으로 수신 중인 프로세스를 확인하세요. “연결 실패”라는 마지막 한 줄만 캡처하거나 전체 구독 링크와 인증 정보를 공개하지 마세요.

최종 점검과 복구: 전체 네트워크에 적용하기 전에

바이패스 라우터는 중앙에서 관리할 수 있다는 장점이 있지만 장애 영향 범위도 커집니다. 단일 기기에서 시험 운영할 때는 재부팅, DNS 질의, LAN 접속, 직접 연결과 프록시 아웃바운드, UDP, IPv6를 최소한 점검해야 합니다. 이 확인을 마치기 전까지 메인 라우터의 기존 DHCP 설정을 유지하고 전체 네트워크의 게이트웨이를 서둘러 바꾸지 마세요.

  1. 재부팅 후 확인: OpenWrt를 재부팅한 뒤 코어 서비스, DNS, 투명 프록시 규칙, 정책 라우팅이 모두 복구되고 규칙이 중복되지 않는지 확인하세요.
  2. LAN 접속 확인: 메인 라우터 관리 페이지, 파일 공유, 기타 로컬 서비스에 접속해 LAN 제외 규칙이 정상적으로 작동하는지 확인하세요.
  3. 장애 시 동작 확인: 코어를 중지하고 가로채던 연결이 어떻게 되는지 살펴보세요. 장애 시 우회 경로를 명확히 설계하지 않았다면 프록시 트래픽은 대개 실패하며 자동으로 직접 연결된다고 볼 수 없습니다.
  4. 복구 절차 확인: 테스트 기기의 게이트웨이와 DNS를 원래 값으로 되돌린 다음 사용자 지정 트래픽 처리 규칙과 정책 라우팅을 제거하세요. 코어만 중지하고 리디렉션 규칙을 남겨 두면 인터넷 연결이 끊길 수 있습니다.
  5. 마지막에 전체 적용: 메인 라우터의 DHCP에서 바이패스 라우터 게이트웨이와 DNS를 할당하도록 설정한 뒤 클라이언트 임대를 갱신하고 실제로 받은 주소를 일부 기기에서 확인하세요. 고정 IP를 사용하는 기기는 별도로 처리해야 합니다.
v2rayN 다운로드플랫폼과 설치 파일 보기