이 글은 OpenWrt에 로그인할 수 있고 IP 라우팅과 기본적인 JSON을 이해하는 사용자를 대상으로 합니다. 먼저 테스트 기기 한 대로 바이패스 라우터 게이트웨이를 확인한 뒤, 명시적 프록시와 투명 프록시를 구분하고 DNS, 코어 라우팅, 방화벽 규칙을 설정합니다. 예시 주소와 포트는 네트워크 구성을 설명하기 위한 것으로, 실제 환경에 그대로 적용할 수 있는 완성형 설치 스크립트가 아닙니다.
바이패스 라우터와 메인 라우터의 경로부터 확인
바이패스 라우터는 네트워크에 연결하기만 하면 전체 트래픽을 자동으로 처리하는 장비가 아닙니다. LAN 기기가 트래픽을 바이패스 라우터로 보내거나, 메인 라우터에 설정된 정책이 지정한 트래픽을 전달해야 합니다. 이 글에서는 단일 LAN 포트와 동일 서브넷을 사용하는 구성을 예로 듭니다. 메인 라우터는 인터넷 연결과 DHCP를 담당하고, OpenWrt는 지정된 기기의 트래픽을 받아 직접 연결할지 Xray 아웃바운드로 보낼지 판단합니다.
| 장치 또는 항목 | 예시 값 | 역할 |
|---|---|---|
| 메인 라우터 LAN | 192.168.10.1/24 | 상위 네트워크에 연결하고 DHCP 서비스 유지 |
| OpenWrt LAN | 192.168.10.2/24 | 테스트 기기의 IPv4 게이트웨이로 사용 |
| OpenWrt 기본 게이트웨이 | 192.168.10.1 | 바이패스 라우터 자체가 상위 네트워크에 연결되도록 설정 |
| 테스트 기기 | 192.168.10.100/24 | 게이트웨이를 수동으로 지정하고, 우선 전체 네트워크의 DHCP는 변경하지 않음 |
| 테스트 기기 게이트웨이 | 192.168.10.2 | 로컬 서브넷이 아닌 트래픽을 바이패스 라우터로 전달 |
상위 네트워크로 나가는 경로는 ‘기기 → OpenWrt → 메인 라우터 → 상위 네트워크’입니다. 같은 서브넷에 있는 기기끼리의 통신은 보통 2계층 네트워크에서 직접 이루어지므로 기본 게이트웨이를 바꿔도 자동으로 바이패스 라우터를 거치지 않습니다. OpenWrt의 기본 게이트웨이는 계속 메인 라우터를 가리켜야 합니다. 메인 라우터의 기본 게이트웨이까지 바이패스 라우터로 바꾸면 라우팅 루프가 생길 수 있습니다.
Xray 코어, 클라이언트, 투명 프록시의 차이
Xray는 인바운드, 라우팅, 아웃바운드를 처리하는 코어이며 OpenWrt 네트워크 관리용 웹 인터페이스는 제공하지 않습니다. v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트, v2flyNG는 v2fly 코어를 사용하는 Android 클라이언트입니다. 각 클라이언트의 구독 관리 화면은 OpenWrt 서비스 설정과 다르며, 구독 주소를 Xray JSON 설정 파일로 사용할 수도 없습니다.
먼저 명시적 프록시 테스트
권장먼저 기기 한 대에서 바이패스 라우터의 SOCKS 인바운드에 직접 연결합니다. 원격 아웃바운드가 정상 작동하는지 확인한 다음 투명 전달 규칙을 추가하면 프로토콜 설정과 코어 트래픽 전달을 동시에 점검해야 하는 상황을 줄일 수 있습니다.
권장 상황: 첫 구축, 노드 설정 확인, 아웃바운드 오류 진단
그다음 투명 프록시 연결
기기에서는 게이트웨이만 지정하고, OpenWrt 방화벽과 정책 라우팅이 선택된 TCP·UDP 트래픽을 Xray로 전달합니다. 일반적으로 앱에서 프록시 주소를 따로 설정할 필요는 없지만, 전달 경로는 더 복잡해집니다.
권장 상황: 기본 검증을 마치고 여러 LAN 기기를 연결할 때
명시적 프록시는 프록시 포트에 직접 연결하는 앱만 처리하지만, 투명 프록시는 네트워크 계층에서 트래픽을 가로채야 합니다. Xray만 실행하거나 인바운드 포트 하나만 열거나 기기의 게이트웨이만 바꾸는 것으로는 투명 프록시가 구성되지 않습니다. Linux 포워딩, 방화벽 매칭, 정책 라우팅, 올바른 응답 경로 처리도 필요합니다.
OpenWrt 기본 설정을 순서대로 확인
아래 메뉴는 일반적인 LuCI 한국어 인터페이스를 기준으로 설명합니다. 번역이나 테마에 따라 메뉴 이름이 조금 다를 수 있습니다. OpenWrt 22.03부터 기본 방화벽은 firewall4와 nftables이며, 이전 버전에서는 firewall3과 iptables를 주로 사용합니다. 먼저 설치된 시스템을 확인한 뒤 그에 맞는 규칙을 선택하세요. 두 방식의 명령을 한 시작 스크립트에 섞어 넣지 마세요.
-
시스템 확인
‘상태’ → ‘개요’에서 펌웨어 버전과 대상 플랫폼을 확인하고, 터미널에서
ubus call system board와uname -m을 실행합니다. 코어 프로그램은 기기 아키텍처와 실행 환경에 맞아야 합니다. 데스크톱 설치 파일을 라우터에서 실행할 수는 없습니다. -
주소 설정
‘네트워크’ → ‘인터페이스’ → ‘LAN’ → ‘편집’ → ‘일반 설정’에서 프로토콜을 ‘고정 주소’로 설정하고, 예시 주소
192.168.10.2, 넷마스크255.255.255.0, IPv4 게이트웨이192.168.10.1을 입력합니다. 실제 서브넷에 맞게 값을 바꾼 뒤 저장하고 적용하세요. -
중복 DHCP 비활성화
‘네트워크’ → ‘인터페이스’ → ‘LAN’ → ‘편집’ → ‘DHCP 서버’ → ‘일반 설정’에서 ‘이 인터페이스 무시’를 선택해 메인 라우터가 주소 할당을 계속 담당하도록 합니다. 이 단계는 이 글에서 다루는 동일 서브넷 구성에 해당하며, OpenWrt가 별도의 하위 네트워크를 관리하는 구성에는 적용되지 않습니다.
-
OpenWrt 자체의 네트워크 연결 확인
‘시스템’ → ‘시스템’에서 시간과 시간대를 확인한 다음 기본 경로, 도메인 이름 확인, 상위 네트워크 연결 상태를 점검합니다. 시스템 시간이 크게 어긋나면 TLS 연결에 문제가 생길 수 있습니다. OpenWrt 자체의 인터넷 연결이 정상적이지 않다면 투명 프록시 규칙부터 조정하지 마세요.
-
코어 실행 테스트
펌웨어에 맞는 신뢰할 수 있는 소프트웨어 저장소에서 Xray를 설치하거나 배포한 뒤
xray version을 실행해 실제 버전을 확인합니다.xray run -test -config /etc/xray/config.json으로 설정을 검사합니다. 파일 경로는 이 글에서 정한 예시이므로 서비스가 실제로 읽는 경로는 시작 스크립트에서 확인해야 합니다.
테스트를 통과했다는 것은 설정 파일을 읽을 수 있다는 뜻일 뿐, 원격 서버에 연결된다는 뜻은 아닙니다. 서버 주소, 포트, 프로토콜, 전송 방식, TLS 매개변수를 계속 확인하세요. VMess나 VLESS를 사용할 때는 제공된 설정을 항목별로 대조하고, 프로토콜 이름만 보고 security, flow 또는 전송 설정을 추측하지 마세요.
ubus call system board
uname -m
ip -4 route show
sysctl net.ipv4.ip_forward
xray version
xray run -test -config /etc/xray/config.json
위 명령은 확인과 테스트용이며 방화벽을 설정하지 않습니다. 트래픽 전달 요구사항에 따라 net.ipv4.ip_forward를 활성화하고, 방화벽에서 필요한 LAN 포워딩을 허용했는지도 확인하세요. 문제를 진단한다며 방화벽 전체를 끄거나 상위 네트워크 인터페이스에 프록시 인바운드를 공개하지 마세요.
투명 인바운드, 트래픽 마킹, 루프 방지 설정
투명 프록시 진입 방식으로는 REDIRECT와 TPROXY가 흔히 사용됩니다. REDIRECT는 보통 TCP 리디렉션에 쓰이며, TCP 설정만으로 완전한 UDP 처리를 구현할 수는 없습니다. TPROXY는 TCP와 UDP를 처리할 수 있지만 이에 맞는 커널 모듈, 방화벽 규칙, 정책 라우팅이 필요합니다. 이 글에서는 각 계층의 관계를 설명하기 위해 TPROXY를 사용하며, 특정 펌웨어와 무관하게 적용할 수 있는 ‘원클릭 규칙’은 제공하지 않습니다.
아래 값은 구성을 위한 예시이지 성능 측정 결과가 아닙니다. 포트 12345는 방화벽의 TPROXY 대상 포트와 일치해야 합니다. 라우팅 테이블 100은 선택 가능한 번호일 뿐이므로 사용하기 전에 다른 서비스가 이미 사용 중인지 확인하세요. 마크 값도 기존 멀티 WAN 연결이나 정책 라우팅 규칙과 충돌하지 않도록 통일해 설계해야 합니다.
{
"inbounds": [
{
"tag": "lan-tproxy",
"listen": "0.0.0.0",
"port": 12345,
"protocol": "dokodemo-door",
"settings": {
"network": "tcp,udp",
"followRedirect": true
},
"streamSettings": {
"sockopt": {
"tproxy": "tproxy"
}
}
}
]
}
- 가로채기 계층: LAN 인바운드에서 테스트 기기를 식별하고 지정된 TCP·UDP 트래픽만 투명 인바운드로 전달합니다. 모든 인터페이스의 트래픽을 무조건 가로채지 마세요.
- 라우팅 계층: 마킹된 패킷이 정책 라우팅을 통해 로컬 수신 경로로 전달되도록 설정합니다.
ip rule show와ip route show table 100으로 규칙이 실제로 있는지 확인하세요. - 제외 계층: LAN, 루프백, 멀티캐스트 등 프록시를 거치면 안 되는 대상 주소를 제외하고, 실제 환경에 따라 다른 예약 대역도 제외합니다.
- 루프 방지: Xray가 원격 서버로 보내는 연결이 다시 가로채지지 않도록 합니다. 출발지, 대상 엔드포인트 또는 전용 마크를 기준으로 우회 규칙을 설계하세요. 특히 도메인 엔드포인트가 해석된 뒤 주소가 바뀔 수 있다는 점에 유의해야 합니다.
- 응답 경로 계층: 같은 서브넷을 사용하는 단일 인터페이스 구성에서는 직접 연결의 응답이 바이패스 라우터를 거치지 않을 수 있습니다. 네트워크 구성에 따라 선택적 SNAT, ICMP 리디렉션, 연결 추적을 검토하세요. SNAT를 사용하면 원래 기기 주소가 숨겨지므로 무조건 전체 트래픽에 적용하지 마세요.
방화벽 분기와 Xray 라우팅을 분리
OpenWrt 방화벽은 ‘어떤 패킷을 Xray로 보낼지’를 결정하고, Xray의 routing.rules는 ‘코어에 들어온 뒤 어떤 아웃바운드로 보낼지’를 결정합니다. 방화벽 단계에서 연결이 우회되면 Xray가 해당 연결을 보지 못하므로 정교한 도메인 규칙도 적용되지 않습니다. 방화벽은 필요한 주소 제외와 연결 범위만 담당하게 하고, 도메인과 서비스 분류는 코어 라우팅에서 관리하는 편이 좋습니다.
| 처리 위치 | 설정 내용 | 확인 방법 |
|---|---|---|
| OpenWrt 방화벽 | 출발 기기 선택, 예약 주소 제외, 투명 포트로 전달 | 규칙 카운터와 LAN 인바운드 트래픽 확인 |
| Linux 정책 라우팅 | 마크 매칭, 로컬 라우팅 테이블 | ip rule과 해당 라우팅 테이블 확인 |
| Xray 라우팅 | 도메인, 대상 주소, 포트, 인바운드 태그 매칭 | 액세스 로그에서 인바운드 및 아웃바운드 태그 확인 |
| Xray 아웃바운드 | 원격 프로토콜 매개변수, 직접 연결 및 거부 동작 | 직접 연결 대상과 프록시 대상 각각 테스트 |
Xray 라우팅은 규칙 순서대로 매칭하며 먼저 일치한 규칙이 아웃바운드를 결정합니다. 명확한 LAN 대상과 예외 규칙을 포괄적인 규칙보다 앞에 두어, 넓은 범위의 규칙이 뒤의 세부 조건을 먼저 처리하지 않도록 하세요. outboundTag는 실제 아웃바운드의 tag와 정확히 일치해야 합니다. 해당 아웃바운드를 빠뜨린 채 라우팅 규칙만 복사하지 마세요.
domainStrategy: AsIs는 IP 라우팅 규칙과 비교하기 위해 도메인을 직접 조회하지 않습니다.IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 도메인을 조회한 뒤 IP 규칙으로 다시 매칭할 수 있습니다. ‘모든 DNS를 프록시로 보내는’ 옵션은 아닙니다.- 투명 연결은 대상 IP를 사용해 코어에 들어오는 경우가 많습니다. 도메인 규칙의 적용 여부는 DNS 구성이나 스니핑으로 도메인 정보를 얻을 수 있는지에 달려 있으며, 스니핑으로 모든 프로토콜의 도메인 정보를 복구할 수 있는 것은 아닙니다.
geosite또는geoip에 의존한다면 데이터 파일이 존재하고 경로가 올바르며 분류 결과가 예상과 맞는지 확인하세요. 파일 누락을 서버 장애로 오인하지 마세요.
DNS와 IPv6 연결은 별도로 설계
IPv4 게이트웨이만 바꿨다고 DNS와 IPv6 트래픽까지 바이패스 라우터로 들어오는 것은 아닙니다. 기기에서 DNS 요청을 여전히 메인 라우터로 보낼 수도 있고, 메인 라우터가 알린 IPv6 기본 경로를 통해 상위 네트워크에 직접 연결할 수도 있습니다. 테스트 기기가 바이패스 라우터를 통해 도메인을 확인하게 하려면 DNS를 192.168.10.2로 지정할 수 있지만, 해당 주소에서 사용 가능한 DNS 서비스가 실행 중이어야 합니다.
- DNS 진입점을 하나로 정하세요. 일반적인 방법은 OpenWrt의 dnsmasq가 LAN의
53번 포트 요청을 받은 뒤 명확한 정책에 따라 전달하도록 하는 것입니다. 같은 주소와 포트를 다른 DNS 프로세스가 점유하지 않았는지 먼저 확인하세요. - DNS 조회 루프 방지. dnsmasq가 로컬의 다른 DNS 서비스로 요청을 전달한다면, 해당 서비스의 상위 DNS가 다시 dnsmasq를 가리키지 않도록 해야 합니다. 프록시 서버 주소가 도메인 이름인 경우에는 아직 연결되지 않은 프록시에 의존하지 않는 초기 DNS 경로도 마련해야 합니다.
- 코어 DNS와 구분.Xray의
dns설정은 코어 관련 도메인 조회를 처리하며, LAN 기기가 자동으로 이 DNS를 사용한다는 뜻은 아닙니다. 기기의 요청이 실제 DNS 수신 및 전달 경로를 거쳐야 합니다. - 암호화 DNS 확인.브라우저나 앱에서 사용하는 자체 암호화 DNS는 시스템 DNS 설정을 따르지 않을 수 있습니다. 테스트할 때 어떤 조회 경로를 사용하는지 명확히 하세요. 한 번 실행한
nslookup결과만으로 모든 앱을 판단하지 마세요. - IPv6 확인.기기의 IPv4와 IPv6 기본 경로를 각각 확인하세요. IPv6 트래픽까지 처리하려면 라우터 알림, IPv6 방화벽, 투명 전달을 별도로 설계해야 합니다. 아직 처리하지 않을 계획이라면 테스트 기기에서 테스트 범위를 명확히 제한하세요.
기기 한 대로 검증한 다음 연결 범위 확대
테스트 기기의 주소를 192.168.10.100, 게이트웨이를 192.168.10.2로 설정합니다. 먼저 메인 라우터 관리 페이지, LAN 기기, 일반 직접 연결 대상에 접속되는지 확인한 뒤 프록시가 필요한 대상을 테스트하세요. TCP 웹 접속이 성공한 다음에는 UDP 앱과 DNS를 각각 확인합니다. 웹페이지 하나가 열린다고 투명 프록시 경로 전체가 정상이라는 뜻은 아닙니다.
게이트웨이를 바꾸자 네트워크가 끊겼다면 어디부터 확인할까요?
먼저 게이트웨이를 메인 라우터로 되돌려 연결을 복구한 다음 OpenWrt의 기본 경로, net.ipv4.ip_forward, LAN 포워딩 정책을 확인하세요. 투명 가로채기를 꺼도 연결되지 않는다면 원격 프로토콜 매개변수를 바꾸기 전에 기본 포워딩과 응답 경로를 점검하세요.
명시적 프록시는 되는데 투명 프록시는 안 되나요?
방화벽 규칙의 매칭 카운터, 투명 인바운드 포트, 정책 라우팅 테이블을 대조하세요. TPROXY에 필요한 모듈과 서비스 권한도 확인해야 합니다. 같은 기기와 같은 대상을 사용해 테스트하고, Xray에 해당 인바운드 기록이 남는지 확인하세요. 기록이 없다면 먼저 트래픽이 들어오는 경로를 점검합니다.
웹은 열리는데 음성 채팅이나 게임은 연결되지 않나요?
UDP가 가로채지고 있는지, 인바운드에 udp가 포함되어 있는지, 원격 연결이 필요한 UDP 전달을 지원하는지, 방화벽이 응답 패킷을 허용하는지 각각 확인하세요. TCP 리디렉션을 활성화했다고 UDP 투명 프록시까지 설정된 것은 아닙니다.
일부 기기가 바이패스 라우터를 거치지 않는 이유는 무엇인가요?
해당 기기의 현재 기본 게이트웨이, IPv6 경로, 방화벽의 출발지 주소 매칭을 확인하세요. 게이트웨이를 수동으로 바꾸면 설정한 기기에만 적용됩니다. 연결 범위를 넓히려면 먼저 검증을 마친 뒤 메인 라우터의 DHCP 게이트웨이 옵션으로 배포하고, 기기에서 임대를 갱신해야 합니다.
기기 한 대의 검증을 마친 뒤 메인 라우터의 DHCP 옵션 3으로 바이패스 라우터의 IPv4 게이트웨이를 배포하고, 옵션 6으로 확인된 DNS 주소를 배포하는 방안을 검토하세요. 세부 설정 화면은 메인 라우터 펌웨어에 따라 다릅니다. 원래 게이트웨이로 복구할 방법을 기록해 두고 기기가 이전 임대 정보를 계속 사용할 수 있다는 점에 유의하세요. 복구 경로 없이 한 번에 전체 네트워크 설정을 변경하지 마세요.
- 설정 유지 확인:재부팅 후에도 Xray 서비스, 정책 라우팅, 방화벽 규칙이 유지되는지 확인하세요. 명령줄에서만 임시로 적용된 상태가 되지 않도록 합니다.
- 규칙 관리 주체 확인:관리 구성 요소가 설정을 생성한다면 같은 파일과 규칙 체인을 수동으로 동시에 관리하지 마세요. 업데이트 과정에서 서로 덮어쓸 수 있습니다.
- 로그 비용 확인:문제 해결 중에만 로그 수준을 높이고, 점검이 끝나면 적절한 수준으로 되돌리세요. 장기간 로그를 자주 기록하면 저장 공간과 기기에 부담을 줄 수 있습니다. 로그를 공유하기 전에 접속 대상, 인증 정보, 기기 식별 정보를 삭제하세요.
- 실제 부하 확인:CPU, 메모리, 연결 수, 온도를 살펴보세요. 처리량은 하드웨어, 프로토콜, 네트워크 조건에 따라 달라지므로 인바운드 포트나 기기 이름만으로 고정 속도를 예상할 수 없습니다.
고급 핸드북에서 라우팅 규칙 순서와 DNS 설정을 확인하고, 용어가 헷갈린다면 용어집에서 인바운드, 아웃바운드, 시스템 프록시의 차이를 살펴보세요. 바이패스 라우터 구축의 핵심은 각 단계를 순서대로 검증하는 것입니다. 기본 네트워크 연결을 확인한 다음 코어 아웃바운드를 테스트하고, 마지막으로 투명 전달을 연결하세요.