OpenWrt 투명 프록시 설정: 보조 라우터에서 Xray 실행하기

보조 라우터의 위치와 트래픽 경로부터 정하기

보조 라우터는 프록시 프로토콜이 아니라 네트워크에서의 배치 역할입니다. 메인 라우터는 인터넷 연결과 DHCP를 담당하고, 보조 라우터는 일부 단말의 게이트웨이와 DNS를 맡을 수 있습니다. 트래픽이 실제로 보조 라우터를 거쳐야 투명 프록시 규칙이 적용될 수 있습니다. 같은 LAN의 기기에 Xray를 설치하는 것만으로 다른 단말의 트래픽까지 자동으로 처리되지는 않습니다.

같은 서브넷을 사용하는 단일 인터페이스 보조 라우터를 예로 듭니다. 메인 라우터는 192.168.10.1, OpenWrt는 192.168.10.2, 테스트 PC는 192.168.10.100입니다. 보조 라우터의 기본 경로는 계속 메인 라우터를 가리킵니다. 먼저 테스트 PC의 IPv4 게이트웨이와 DNS를 보조 라우터 주소로 수동 변경하고, 다른 기기는 기존 네트워크를 그대로 사용합니다.

단일 인터페이스 전달 구성에서는 동일 인터페이스 간 전달, 응답 경로, ICMP 리디렉션도 고려해야 합니다. 메인 라우터가 응답 패킷을 단말에 직접 전달하면 보조 라우터가 직접 연결 세션 전체를 보지 못할 수 있습니다. SNAT 필요 여부는 응답 경로와 연결 추적 결과를 바탕으로 판단해야 합니다. 모든 토폴로지에서 NAT를 켜는 것이 정답은 아닙니다. 테스트 중에는 이후 게이트웨이 선택에 영향을 주는 리디렉션을 보조 라우터가 단말에 보내는지도 확인하세요.

투명 가로채기 전에 노드 필드에 맞는 코어 선택하기

v2rayN은 데스크톱 클라이언트이고 Xray와 V2Fly는 프록시 코어입니다. OpenWrt에서는 데스크톱 UI 없이 코어 프로세스를 직접 실행하고 서비스 관리자가 JSON 설정을 읽도록 구성할 수 있습니다. 구독 가져오기, 노드 전환, 투명 전달은 서로 다른 기능입니다. 바이너리를 설치한 뒤에도 설정 생성, 서비스 시작, 방화벽 연동이 필요합니다.

설치 전 CPU 아키텍처, 펌웨어 패키지 저장소, 사용 가능한 저장 공간을 확인하세요. OpenWrt 24.10.x는 기본적으로 firewall4와 nftables를 사용하므로 구버전 iptables용 명령을 그대로 섞어 쓰면 안 됩니다. TPROXY에는 펌웨어에서 관련 커널 모듈도 제공되어야 합니다. 패키지 설치와 코어 실행에 성공했다고 해서 패킷 가로채기 경로까지 정상인 것은 아닙니다.

ubus call system board
uname -m
xray version
nft list ruleset
ip rule show
ip route show table all

패키지 이름만 기록하지 말고 실제로 출력된 코어 버전을 확인하세요. 업그레이드 후에는 설정을 다시 테스트해야 합니다. 특히 노드에 REALITY, fingerprint 또는 특정 전송 필드가 포함된 경우 주의하세요. OpenWrt의 설정 경로는 패키지와 시작 스크립트에 따라 다르므로, 아래에서는 /etc/xray/config.json을 예로 듭니다.

dokodemo-door, TPROXY, 정책 라우팅의 연동 방식

dokodemo-door는 트래픽을 받는 인바운드를 제공합니다. followRedirect를 활성화하면 투명 가로채기 방식에 따라 원래 목적지 주소를 가져올 수 있습니다. 하지만 nftables 규칙을 만들거나 시스템의 정책 라우팅을 설정해 주지는 않습니다. inbounds에 포트만 추가해도 단말 트래픽이 자동으로 해당 포트에 들어오지는 않습니다.

다음은 TCP와 UDP를 12345 포트에서 받는 Xray 인바운드 설정 예시입니다. inbounds 부분만 보여 주며, 실제로 실행하려면 유효한 outbounds, 로그 설정, 방화벽 구성이 추가로 필요합니다. 로컬 투명 전달을 위해 모든 IPv4 주소에서 수신하도록 했으므로 방화벽에서 접근 출처를 제한해야 합니다. 이 포트를 공인 인터넷에 노출하지 마세요.

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

0x1과 테이블 번호 100은 이 예시에서 정한 값일 뿐입니다. 배포 전에 다른 정책 라우팅과 충돌하지 않는지 확인하세요. 프록시 프로세스 자체의 연결은 별도의 우회 조건으로 처리해야 합니다. 예를 들어 아웃바운드의 sockopt.mark에 가로채기 mark와 다른 값을 설정하고 규칙에서 먼저 반환하도록 합니다. 그렇지 않으면 프록시 서버 연결이 다시 투명 인바운드로 들어가 루프가 발생할 수 있습니다.

• 가로채기 전에 보조 라우터 자체 주소, 관리 대역, 브로드캐스트, 멀티캐스트 등 프록시로 보내면 안 되는 목적지를 제외하세요.
• 프록시 서버 주소와 프록시 프로세스 트래픽은 별도로 처리하고, 도메인 노드의 주소 변경도 업데이트 정책에 반영하세요.
• PREROUTING은 주로 장치를 통과하는 트래픽을 처리합니다. 장치 자체에서 시작한 트래픽은 OUTPUT과 관련되므로 같은 TPROXY 규칙을 그대로 적용할 수 없습니다.
• REDIRECT는 주로 TCP 리디렉션에 사용됩니다. UDP도 필요하다면 TCP만 가로채는 방화벽 규칙은 그대로 둔 채 인바운드의 network만 바꿔서는 안 됩니다.

이 글에서는 모든 펌웨어에 통용되는 nftables 전체 스크립트를 제공하지 않습니다. firewall4가 지원하는 영구 설정 방식으로 규칙을 추가하고 체인의 hook, 우선순위, 방화벽 영역 권한을 확인하세요. 임시 명령이 성공해도 방화벽을 다시 불러온 뒤 규칙이 유지된다는 보장은 없습니다.

routing 분할과 DNS 분할은 따로 검증하기

방화벽은 어떤 패킷을 코어에 전달할지 결정하고, routing은 전달된 패킷에 사용할 아웃바운드를 선택합니다. 서로 대체할 수 있는 기능이 아닙니다. Xray 라우팅 규칙은 순서대로 적용되므로 LAN 직접 연결 같은 명확한 예외를 앞에 두고, 그다음 프록시 대상에 대한 규칙을 배치하세요. 일치하는 규칙이 없으면 보통 첫 번째 아웃바운드가 사용되므로 outbounds의 순서도 점검해야 합니다.

다음은 라우팅 설정 예시입니다. 기존 설정에 direct라는 직접 연결 아웃바운드와 유효한 노드 아웃바운드 proxy가 있다고 가정합니다. 투명 인바운드에서 들어온 나머지 트래픽을 프록시로 보내는 넓은 범위의 규칙이며, 완성된 지역별 분할 규칙은 아닙니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["transparent-in"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatch가 모든 도메인을 먼저 해석한 뒤 분할한다는 뜻은 아닙니다. 원래 목적지가 도메인이고 이미 규칙에 일치하면 라우팅 매칭을 위한 DNS 조회가 실행되지 않을 수 있습니다. 투명 연결에 목적지 IP만 전달되면 도메인 규칙이 도메인을 저절로 알아내지 못합니다. 필요에 따라 sniffing을 검토할 수 있지만, 모든 암호화 프로토콜을 식별하지는 못하며 DNS 설계를 대신할 수도 없습니다.

• 단말 DNS 조회 경로: 테스트 PC가 192.168.10.2:53으로 조회를 보내고 dnsmasq가 계획된 업스트림을 선택하도록 설정하세요. 상위와 하위 DNS가 서로에게 요청을 전달하는 루프를 방지해야 합니다.
• 노드 도메인 조회: 프록시 연결이 아직 성립하지 않았을 때도 노드 주소를 조회할 수 있어야 합니다. 노드의 첫 DNS 조회가 아직 연결되지 않은 프록시에 전적으로 의존하지 않도록 하세요.
• 조회와 연결의 출구: 원격 DNS 조회 결과와 최종 트래픽 출구가 서로 맞도록 구성하세요. DNS가 선택한 주소에 실제 출구에서 접근할 수 없는 상황을 피해야 합니다.
• 앱 자체 DNS: 브라우저의 암호화 DNS는 일반 53번 포트를 거치지 않습니다. 테스트할 때 관련 설정도 기록해야 보조 라우터의 DNS가 작동하지 않는다고 잘못 판단하지 않습니다.
• IPv6 경로: AAAA 레코드, IPv6 기본 경로, IPv6 트래픽 가로채기를 함께 확인하세요. IPv4만 설정했다고 IPv6도 프록시를 거치는 것은 아닙니다.

5단계로 배포하기: 단일 클라이언트부터 시작

트래픽 진입점을 바꾸기 전에 관리 경로를 하나 확보하세요. 아래 메뉴는 OpenWrt 24.10.x의 일반적인 LuCI 화면을 기준으로 하며 테마와 번역에 따라 조금 다를 수 있습니다. 주소를 변경하기 전에 설정을 백업하고 메인 라우터 주소를 기록해 두세요. 문제가 생기면 테스트 PC를 원래 게이트웨이로 되돌릴 수 있습니다.

1. 네트워크 설정 백업

   「시스템」→「백업/업그레이드」에서 설정 백업을 만듭니다. 현재 LAN 주소, DHCP 설정, 방화벽 영역을 기록하세요. 원격 연결 중에 규칙 전체를 한꺼번에 바꾸지 마세요.

2. 보조 라우터 IP 고정

   「네트워크」→「인터페이스」→「LAN」→「편집」→「일반 설정」에서 고정 주소 192.168.10.2, 서브넷 마스크 255.255.255.0, IPv4 게이트웨이 192.168.10.1을 확인합니다. 「DHCP 서버」→「일반 설정」에서 보조 라우터가 중복으로 주소를 할당하지 않는지 확인하세요.

3. 코어 동작 확인

   사용 가능한 기존 노드로 아웃바운드 설정을 완성한 뒤 설정 테스트를 실행합니다. 서비스 로그가 정상인지 확인하고 12345 포트가 수신 중인지 점검하세요. 이 단계에서는 전체 네트워크의 게이트웨이를 바꾸거나 모든 단말을 대상으로 가로채기 규칙을 열지 않습니다.

4. 단말 한 대만 가로채기

   테스트 PC의 게이트웨이와 DNS를 192.168.10.2로 바꾸고 가로채기 규칙은 출발지 192.168.10.100에만 적용합니다. 먼저 TCP, 다음으로 UDP를 테스트하면서 nftables 카운터, 인바운드 기록, 아웃바운드 태그를 단계별로 확인하세요.

5. 영구 설정 후 재검증

   「네트워크」→「DHCP/DNS」→「일반 설정」에서 DNS 전달 대상을 확인합니다. 로컬 콘솔에서 방화벽을 다시 불러오고 기기를 재부팅한 뒤 규칙, 정책 라우팅, 서비스 시작을 다시 테스트하세요. 모두 통과한 후에 DHCP로 게이트웨이를 배포하는 범위를 넓힙니다.

xray run -test -config /etc/xray/config.json
ss -lnptu
logread | grep -i xray
nft list ruleset
ip rule show
ip route show table 100
nslookup example.com 192.168.10.2

위 명령은 상태 확인용입니다. 펌웨어에 ss가 설치되어 있지 않다면 해당 진단 도구를 설치하거나 펌웨어에 포함된 소켓 확인 명령을 사용하세요. 설정 테스트 통과는 코어가 설정을 받아들였다는 뜻일 뿐 원격 노드에 연결할 수 있다는 보장은 아닙니다. DNS 조회 성공도 해당 조회에서 응답을 받았다는 뜻이지 웹 요청이 올바른 아웃바운드를 선택했다는 뜻은 아닙니다.

DNS는 되지만 접속이 안 되거나 UDP가 실패할 때

패킷이 이동하는 순서대로 문제를 확인하세요. 먼저 테스트 PC의 게이트웨이를 확인하고, 다음으로 가로채기 카운터와 코어 로그를 살핀 뒤 원격 연결을 점검합니다. 한 번의 테스트에서 DNS, 노드, 방화벽을 동시에 바꾸지 마세요. 접속이 복구되더라도 어떤 변경이 원인이었는지 알기 어려워집니다.

성능을 확인할 때는 테스트 조건을 고정하세요. 예를 들어 같은 HTTPS 요청을 연속 10회 보내고 성공 횟수, 연결 시간, 다운로드 중 CPU 사용률을 기록한 뒤 단일 연결과 다중 연결 결과를 비교합니다. 이는 권장 측정 방법이며 이 글에서 직접 측정한 성능 수치가 아닙니다. 라우터의 표기된 이더넷 포트 속도가 암호화 전달 처리량을 보장하지는 않습니다. CPU, 냉각, MTU, 노드 연결 상태가 모두 병목이 될 수 있습니다.

보조 라우터와 데스크톱 클라이언트의 역할 나누기

보조 라우터는 안정적인 가정 네트워크 정책을 처리하는 데 적합하고, 데스크톱 클라이언트는 집 밖에서 기기별로 연결할 때 유용합니다. 같은 구독을 여러 기기에서 사용할 수 있지만 구독 텍스트를 코어에 바로 넣어 실행할 수 있는 설정 파일로 볼 수는 없습니다. 보조 라우터에서는 노드 아웃바운드, 라우팅 규칙, 업데이트 방식도 따로 구성해야 합니다. 새 노드를 가져올 때 투명 인바운드와 루프 방지 설정을 덮어쓰지 않도록 주의하세요.

배포 완료 기준은 프로세스가 실행 중인 것만으로 충분하지 않습니다. 단말 게이트웨이가 올바르고, 가로채기 경로가 적용되며, DNS 방향이 명확하고, 아웃바운드가 규칙에 맞아야 합니다. 재부팅 후에도 같은 결과가 나와야 합니다. 기존 게이트웨이와 설정 백업을 보관하면 보조 라우터를 유지보수할 때 단말을 메인 라우터로 되돌려 LAN 전체가 노드 업데이트의 영향을 받지 않도록 할 수 있습니다.