라우터와 보조 라우터에서 V2Ray 코어 직접 실행하기: OpenWrt 배포 핵심과 트래픽 가로채기 방식

먼저 메인 라우터와 보조 라우터 중 선택하기

라우터에서 V2Ray를 실행할 때 핵심은 실행 파일을 복사하는 데 있지 않습니다. LAN 기기의 기본 게이트웨이, DNS와 방화벽을 누가 담당할지 결정하는 것이 중요합니다. 메인 라우터 방식은 OpenWrt 한 대가 PPPoE 접속, NAT, DHCP, DNS와 투명 프록시를 모두 맡아 경로가 짧지만, 설정 오류가 가정 전체의 네트워크에 바로 영향을 줍니다. 보조 라우터 방식은 기존 메인 라우터를 유지하고 지정한 기기만 게이트웨이와 DNS를 OpenWrt로 지정하므로 변경 범위가 작고 첫 테스트에 적합합니다.

보조 라우터라고 해서 자동으로 ‘옆에서 감시’할 수 있는 것은 아닙니다. 단말의 기본 게이트웨이가 여전히 기존 메인 라우터이고 OpenWrt가 실제 전달 경로에 있지 않다면 가로챌 패킷을 볼 수 없습니다. 가장 확실한 방법은 테스트 단말에 보조 라우터 주소를 직접 설정하는 것입니다. 예를 들어 메인 라우터가 192.168.1.1, 보조 라우터가 192.168.1.2라면 테스트 단말의 게이트웨이와 DNS를 모두 192.168.1.2로 지정합니다. 검증이 끝난 뒤 메인 라우터 DHCP에서 기기별로 배포하면 됩니다.

하드웨어, 시스템과 디렉터리 준비하기

코어는 라우터의 CPU 아키텍처와 일치해야 합니다. 흔한 아키텍처로는 arm64, armv7, mips와 x86_64가 있으며 기기 브랜드만 보고 판단해서는 안 됩니다. ubus call system board로 시스템 정보를 확인한 다음 uname -m으로 커널이 보고하는 아키텍처를 확인할 수 있습니다. 파일을 업로드한 뒤 not found가 표시되면 파일이 실제로 존재하더라도 먼저 아키텍처와 동적 링크 의존성을 점검하세요.

프로그램, 설정과 실행 데이터를 분리해 두는 것이 좋습니다. 실행 파일은 /usr/bin/v2ray, 기본 설정은 /etc/v2ray/config.json에 저장하고 로그는 필요에 따라 시스템 로그나 충분한 용량의 영구 저장 디렉터리에 기록합니다. 용량이 작은 플래시에 상세 접속 로그를 계속 기록하지 마세요. 문제를 분석할 때만 로그 수준을 임시로 높이고 안정화되면 warning 또는 error로 되돌립니다.

설정 파일, 서비스와 부팅 순서

설정은 먼저 코어에 포함된 테스트 명령으로 검사한 뒤 서비스 관리자를 통해 시작해야 합니다. V2Ray 5 계열 빌드마다 명령 인자가 조금 다를 수 있지만 일반적으로 v2ray test -c /etc/v2ray/config.json 형식을 사용합니다. 현재 빌드가 해당 인자를 인식하지 못하면 먼저 v2ray help로 실제 명령을 확인하세요. 문법 오류 상태에서 서비스를 반복 재시작해서는 안 됩니다.

투명 프록시 인바운드는 보통 dokodemo-door를 사용하며 LAN에서 전달된 TCP와 UDP를 수신합니다. 아래에는 인바운드의 핵심 부분만 표시합니다. 아웃바운드의 서버 주소, 사용자 식별자, 전송 계층과 TLS 매개변수는 실제 노드에 맞게 입력해야 합니다. 예시 포트 12345도 방화벽 규칙과 일치해야 합니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

1. 아키텍처 확인

   터미널에서 uname -m을 실행해 아키텍처에 맞는 V2Ray 코어를 다운로드하고 OpenWrt에 충분한 영구 저장 공간과 사용 가능한 메모리가 있는지 확인합니다.

2. 파일 배치

   프로그램을 /usr/bin/v2ray에, 설정을 /etc/v2ray/config.json에 배치한 다음 chmod 755 /usr/bin/v2ray를 실행합니다.

3. 설정 확인

   먼저 설정 테스트 명령을 실행한 뒤 포그라운드에서 한 번 시작해 로그를 확인합니다. 노드 아웃바운드가 정상적으로 연결되는 것을 확인한 후 부팅 서비스를 만들고 비정상 재시작 정책을 설정하세요.

4. 전달 허용

   OpenWrt의 ‘네트워크’ → ‘방화벽’에서 LAN 영역의 전달 설정을 확인합니다. 보조 라우터라면 커널 IP 전달 매개변수도 활성화되어 있는지 확인해야 합니다.

5. 단일 기기 테스트

   테스트 컴퓨터 한 대의 게이트웨이와 DNS만 보조 라우터 주소로 변경한 뒤 웹 페이지, 동영상, 소프트웨어 다운로드와 UDP가 필요한 앱을 각각 확인합니다.

6. 단계적 전환

   안정적으로 실행된 후 ‘네트워크’ → ‘인터페이스’ → ‘LAN’ → ‘DHCP 서버’에서 게이트웨이와 DNS 배포를 조정하세요. 한 번에 모든 기기에 영향을 주는 일을 피할 수 있습니다.

REDIRECT와 TPROXY, 두 가지 트래픽 가로채기 방식

REDIRECT는 라우터를 통과하는 TCP 연결을 로컬 리스닝 포트로 리디렉션하는 방식입니다. 이해하고 적용하기 쉬워 웹과 일반 TCP 앱을 먼저 검증하기에 좋지만 UDP 투명 프록시를 완전히 처리할 수는 없습니다. 가정 내 기기에서 실시간 통신, 일부 DNS 트래픽 또는 UDP 의존 앱을 사용한다면 최종적으로는 보통 TPROXY가 필요합니다.

TPROXY는 원래 목적지 주소를 직접 바꾸지 않고 패킷에 마크를 설정한 다음 정책 라우팅으로 마크된 트래픽을 로컬 투명 프록시 포트로 보냅니다. 대표적인 조합은 방화벽 마크 0x1, 정책 라우팅 테이블 100, 리스닝 포트 12345입니다. V2Ray 아웃바운드 소켓에도 별도 마크를 설정하고 가로채기 체인에서 제외해야 합니다. 그렇지 않으면 코어가 만든 연결이 다시 자신에게 들어가 루프가 발생합니다.

OpenWrt 23.05 및 이후 계열은 기본적으로 fw4와 nftables를 사용합니다. 오래된 튜토리얼의 iptables 명령을 nftables 규칙과 그대로 섞으면 명령은 성공한 것처럼 보여도 패킷이 예상한 체인으로 들어가지 않을 수 있습니다. 구축할 때 ‘네트워크’ → ‘방화벽’에서 현재 백엔드를 확인하고 nft list ruleset으로 실제 로드된 결과를 확인하세요.

정책 라우팅의 핵심 관계는 다음과 같습니다. 명령은 마크와 라우팅 테이블의 대응 방식을 설명하기 위한 것입니다. 실제 운영에서는 인터페이스 재연결 후에도 복구할 수 있는 스크립트에 넣고, 현재 시스템에 같은 이름의 규칙이 이미 있는지 확인해야 합니다.

ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ip rule show
ip route show table 100

• 라우터 자체의 LAN 주소, 루프백 주소, 멀티캐스트 주소와 예약 주소는 제외해 관리 페이지와 LAN 서비스가 프록시로 전달되지 않도록 합니다.
• 프록시 서버의 실제 IP도 제외해야 합니다. 그렇지 않으면 프록시 터널을 만드는 연결이 다시 투명 프록시 규칙에 걸립니다.
• 먼저 prerouting 경로에서 LAN 전달 트래픽을 가로채고, 처음부터 라우터의 모든 output 트래픽을 가로채지는 마세요.
• IPv4와 IPv6는 서로 다른 경로입니다. IPv6 트래픽 분리를 설정하지 않았다면 직접 연결을 유지할지, 관련 라우팅을 LAN에 당분간 배포하지 않을지 명확히 결정해야 합니다.

DNS는 트래픽 경로와 함께 설계해야 합니다

투명 프록시가 정상이라고 해서 DNS까지 올바르게 구성된 것은 아닙니다. 단말이 계속 메인 라우터나 통신사가 제공하는 DNS 서버에 직접 질의하면 도메인 분리 정책과 실제 연결 경로가 어긋날 수 있습니다. 보조 라우터 테스트에서 게이트웨이는 192.168.1.2로 바꿨지만 DNS는 192.168.1.1로 남아 있는 상태가 가장 흔한 반쪽짜리 가로채기입니다.

V2Ray 설정의 dns 객체는 코어의 이름 확인과 관련 라우팅 로직에 사용되지만, 설정에 존재한다고 해서 자동으로 LAN의 DNS 서비스가 되는 것은 아닙니다. LAN 기기가 이를 사용하게 하려면 DNS 인바운드를 구성하거나 dnsmasq가 규칙에 따라 로컬 포트로 전달하도록 해야 합니다. 이 글의 예시에서는 dnsmasq가 LAN의 53 포트를 수신하고 코어에서 처리해야 하는 요청을 127.0.0.1:1053으로 전달하도록 구성할 수 있습니다.

1. 통합 진입점

   dnsmasq가 LAN의 UDP/TCP 53을 계속 수신하도록 하고 단말의 DNS는 OpenWrt LAN 주소로 통일해 보조 라우터를 우회한 질의를 막습니다.

2. 전달 구성

   V2Ray에 로컬 DNS 인바운드를 구성합니다. 예를 들어 127.0.0.1:1053에서 수신하도록 설정하고 해당 포트를 다른 이름 확인 서비스가 사용하고 있지 않은지 확인합니다.

3. 경로 구분

   로컬 도메인과 LAN 호스트 이름은 계속 dnsmasq가 처리하고 프록시 확인이 필요한 요청만 코어로 전달해 가정 내 기기 이름이 정상적으로 유지되도록 합니다.

4. 루프백 차단

   방화벽 규칙에서 라우터가 상위 DNS로 보내는 연결을 제외해 53 포트 요청이 투명 프록시 규칙에 반복해서 포착되지 않도록 합니다.

5. 항목별 검증

   먼저 라우터에서 이름 확인을 실행하고, 이어서 테스트 단말에서 같은 도메인을 조회합니다. 마지막으로 코어 로그와 nftables 카운터가 동시에 변하는지 확인합니다.

일반적인 장애는 경로를 나눠 점검하기

라우터 투명 프록시는 단말, 게이트웨이, 방화벽, 정책 라우팅, V2Ray 인바운드, V2Ray 아웃바운드와 DNS 등 여러 단계로 구성됩니다. 가장 효과적인 문제 해결 방법은 노드를 계속 바꾸는 것이 아니라 단말부터 아웃바운드까지 각 구간을 차례로 확인하는 것입니다. 먼저 단말이 OpenWrt 관리 주소에 접근할 수 있는지 확인하고, 다음으로 기본 게이트웨이와 DNS를 점검합니다. 이후 12345가 리스닝 중인지, 규칙 카운터가 증가하는지, 코어 로그에 해당 연결이 기록되는지 살펴봅니다.

규칙 카운터가 계속 0이면 문제는 대개 단말 게이트웨이나 방화벽의 가로채기 범위에 있습니다. 카운터는 증가하지만 코어 로그가 없다면 정책 라우팅과 리스닝 주소를 확인하세요. 코어가 요청을 받았지만 아웃바운드에 실패한다면 시스템 시간, 노드 매개변수, 라우팅 규칙과 프록시 서버 IP 제외 설정을 점검합니다. 장애가 발생한 구간을 특정한 뒤 수정해야 여러 변수가 동시에 바뀌는 일을 피할 수 있습니다.

운영 전 최소 검수 목록

가정용 네트워크의 검수 기준은 복구 가능성, 문제 위치 파악과 단계적 확장입니다. 설정을 변경하기 전에 OpenWrt 설정과 V2Ray 설정을 백업하고, 보조 라우터를 거치지 않는 관리 기기 한 대를 남겨 두며, 투명 프록시 규칙을 비활성화하는 명령을 기록하세요. 이렇게 하면 트래픽 분리나 DNS 설정에 문제가 생겨도 관리 화면에 접속해 복구할 수 있습니다.

장기 운영에서는 필요한 로그만 남기세요. 코어를 업그레이드하기 전 별도 포트에서 새 프로그램과 기존 설정의 호환성을 테스트한 다음 서비스 파일을 교체합니다. 설정 파일, 지리 규칙 데이터와 프로그램 버전은 한 세트로 관리해 프로그램 업데이트 후 호환되지 않는 이전 필드를 계속 불러오는 일을 피해야 합니다.

• 테스트 단말의 기본 게이트웨이와 DNS가 모두 의도한 OpenWrt 주소를 가리키는지 확인합니다.
• 라우터의 로컬 관리 페이지, 프린터, 저장 장치와 기타 LAN 주소는 직접 연결 상태를 유지합니다.
• TCP와 UDP를 따로 테스트하며 웹 페이지가 열린다는 이유로 UDP 검수를 대신하지 않습니다.
• 라우터를 재부팅한 뒤 V2Ray 프로세스, 리스닝 포트, 방화벽 체인과 정책 라우팅이 모두 자동으로 복구되는지 확인합니다.
• 투명 프록시를 비활성화하면 LAN이 일반 직접 연결 상태로 돌아와야 합니다.
• 로그 수준을 일상적인 설정으로 되돌리고 플래시 저장 공간과 사용 가능한 메모리가 안정적으로 유지되는지 확인합니다.