네트워크의 모든 트래픽이 프록시를 통해 흐르도록 하려면 — 각 노트북, 스마트폰 또는 서버에서 수동 설정 없이 — OpenWrt 라우터에서 TPROXY를 통한 투명 프록시가 필요합니다. 이 가이드에서는 필요한 패키지 설치부터 iptables 규칙 및 작동 확인까지 전체 구성을 다룹니다.
TPROXY란 무엇이며 왜 필요한가
TPROXY(투명 프록시)는 패킷의 목적지 IP 주소를 변경하지 않고 TCP 및 UDP 트래픽을 가로채는 Linux 커널의 메커니즘입니다. 전통적인 NAT 리디렉션(REDIRECT)와 달리, TPROXY는 원래 수신자의 주소를 유지하여 프록시 클라이언트가 네트워크에서 장치가 연결하려는 정확한 위치를 "볼" 수 있도록 합니다.
실제로 왜 필요할까요? 사무실이나 가정 실험실에 수십 개의 장치가 있다고 상상해 보세요 — 컴퓨터, 스마트폰, IoT 장치, 테스트 가상 머신. 각 장치에서 프록시를 수동으로 설정하는 것은 수 시간의 작업과 프록시 서버 변경 시 지속적인 두통을 초래합니다. 라우터에서 투명 프록시는 중앙 집중식으로 문제를 해결합니다: 네트워크의 모든 트래픽이 자동으로 프록시를 통해 흐르고, 장치는 이를 전혀 인식하지 못합니다.
OpenWrt에서 TPROXY의 일반적인 사용 시나리오는 다음과 같습니다:
- 지리적 차단을 우회하기 위해 레지던트 또는 모바일 프록시를 통한 모든 트래픽 라우팅
- 기업 네트워크에서 트래픽의 중앙 집중식 모니터링 및 필터링
- 클라이언트 머신의 설정을 변경하지 않고 다양한 지역의 프록시를 통한 애플리케이션 테스트
- 라우터에 연결된 모든 장치에 대한 IP 자동 변경
- 단일 게이트웨이를 통해 안티 디텍트 브라우저(Dolphin Anty, AdsPower, GoLogin)와 작업
TPROXY의 주요 장점은 일반 REDIRECT에 비해 UDP를 지원한다는 것입니다. 이는 REDIRECT가 올바르게 처리할 수 없는 현대 프로토콜(QUIC, DNS over UDP, 게임 트래픽)에 중요합니다.
OpenWrt에서 투명 프록시가 작동하는 방식
OpenWrt에서 TPROXY의 작동 방식은 다음과 같습니다:
- 네트워크의 장치가 외부 IP 주소(예:
93.184.216.34:443)로 패킷을 전송합니다. - 라우터는 라우팅 결정이 내려지기 전에 PREROUTING 체인에서
iptables TPROXY규칙으로 패킷을 가로챕니다. - 패킷은 특별한 fwmark로 표시되고 프록시 클라이언트의 로컬 소켓(예: 포트 7893)으로 리디렉션됩니다.
- 프록시 클라이언트(redsocks, Xray, sing-box)는
IP_TRANSPARENT메커니즘을 통해 원래의 목적지 주소를 "보고" 원격 프록시 서버를 통해 연결을 설정합니다. - 응답은 장치로 다시 돌아옵니다 — 투명하게, 클라이언트 측에서 어떤 변경도 없이.
💡 중요한 점
TPROXY는 PREROUTING 체인에서만 작동합니다. 이는 네트워크 장치에서 오는 트랜짓 트래픽만 가로챌 수 있으며, 라우터 자체의 트래픽은 포함되지 않습니다. 라우터의 트래픽을 가로채려면 OUTPUT 및 루프백을 통한 라우팅에 대한 추가 설정이 필요합니다.
요구 사항: 라우터, 펌웨어, 패키지
설정을 시작하기 전에 구성 요소가 최소 요구 사항을 충족하는지 확인하십시오.
라우터 요구 사항
| 매개변수 | 최소 | 권장 |
|---|---|---|
| RAM | 64MB | 256MB 이상 |
| Flash / 저장소 | 16MB | 128MB 이상 |
| CPU 아키텍처 | MIPS, ARM | ARM Cortex-A7/A53 이상 |
| OpenWrt 버전 | 21.02 | 23.05 또는 스냅샷 |
| Linux 커널 | 5.4 TPROXY 포함 | 5.15 / 6.1 |
이 작업에 잘 알려진 모델: GL.iNet GL-MT6000 (Flint 2), Xiaomi AX3000T, Banana Pi BPi-R3, Raspberry Pi 4와 OpenWrt, 그리고 충분한 RAM을 가진 모든 x86 라우터.
TPROXY 지원 확인
SSH를 통해 라우터에 연결하고 다음을 실행하십시오:
zcat /proc/config.gz | grep TPROXY
CONFIG_NETFILTER_XT_TARGET_TPROXY=y 또는 =m라는 줄을 확인해야 합니다. 출력이 비어 있으면 커널이 TPROXY를 지원하지 않으며 재컴파일 또는 펌웨어 변경이 필요합니다.
필요한 패키지 설치
OpenWrt에서 TPROXY를 작동시키기 위해 몇 가지 패키지가 필요합니다. SSH를 통해 연결하고 패키지 목록을 업데이트하십시오:
opkg update
필요한 구성 요소를 설치하십시오:
# TPROXY용 커널 모듈
opkg install kmod-nft-tproxy
# iptables 사용 시 (구형 스택)
opkg install iptables-mod-tproxy
# ip rule / ip route 유틸리티
opkg install ip-full
# fwmark 작업을 위한 추가
opkg install kmod-ipt-tproxy
선택한 프록시 클라이언트에 따라 다음 패키지 중 하나를 설치하십시오:
| 프록시 클라이언트 | OpenWrt 패키지 | TPROXY 지원 |
|---|---|---|
| redsocks | redsocks |
TCP (UDP는 redsocks2를 통해) |
| Xray-core | xray-core |
TCP + UDP (네이티브) |
| sing-box | sing-box |
TCP + UDP (네이티브) |
| mihomo (Clash Meta) | mihomo |
TCP + UDP (네이티브) |
대부분의 작업에 대해 sing-box 또는 mihomo를 권장합니다 — 이들은 UDP를 포함하여 TPROXY를 네이티브로 지원하며 구성 형식이 편리합니다.
iptables 및 ip rule 규칙 설정
이것은 핵심 단계입니다. 우리는 세 가지 작업을 수행해야 합니다: 필요한 패킷에 fwmark를 지정하고, 특별한 라우팅 테이블을 설정하고, iptables에 TPROXY 규칙을 추가합니다.
단계 1: 라우팅 테이블 생성
# 특별한 경로 추가: 표시된 패킷은 루프백으로 이동
ip rule add fwmark 1 table 100
ip route add local default dev lo table 100
이는 커널에 "fwmark=1로 표시된 모든 패킷을 로컬로 간주하고 루프백으로 전달하라"고 지시합니다. 이렇게 하면 프록시 클라이언트가 자신의 소켓을 통해 이를 수신할 수 있습니다.
단계 2: iptables 규칙 (mangle/PREROUTING)
# TPROXY를 위한 체인 생성
iptables -t mangle -N TPROXY_RULES
# 로컬 주소 제외 (프록시하지 않음)
iptables -t mangle -A TPROXY_RULES -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A TPROXY_RULES -d 240.0.0.0/4 -j RETURN
# TCP를 프록시 클라이언트의 포트(7893)로 리디렉션
iptables -t mangle -A TPROXY_RULES -p tcp \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1
# UDP를 프록시 클라이언트의 포트(7893)로 리디렉션
iptables -t mangle -A TPROXY_RULES -p udp \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1
# 트랜짓 트래픽에 체인 적용
iptables -t mangle -A PREROUTING -j TPROXY_RULES
📌 포트 7893
포트 7893는 프록시 클라이언트(sing-box, mihomo, Xray)가 TPROXY 모드에서 수신 대기하는 포트입니다. 클라이언트의 설정과 일치하는지 확인하십시오.
단계 3: 재부팅 시 규칙 저장
/etc/init.d/tproxy에 자동 시작 스크립트를 만들거나 /etc/rc.local에 명령을 추가하십시오. OpenWrt 23.05에서 nftables를 사용하는 경우 iptables 대신 nft 구문으로 유사한 규칙을 사용하십시오:
nft add table ip tproxy_table
nft add chain ip tproxy_table prerouting \
'{ type filter hook prerouting priority mangle; policy accept; }'
nft add rule ip tproxy_table prerouting \
ip daddr { 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } return
nft add rule ip tproxy_table prerouting \
tcp tproxy to 127.0.0.1:7893 meta mark set 1
nft add rule ip tproxy_table prerouting \
udp tproxy to 127.0.0.1:7893 meta mark set 1
프록시 클라이언트 구성: redsocks, Xray, sing-box
라우터의 프록시 클라이언트는 가로챈 트래픽을 수신하고 원격 프록시 서버를 통해 전송하는 프로그램입니다. 가장 인기 있는 옵션에 대한 구성을 살펴보겠습니다.
옵션 1: redsocks (간단, TCP만)
SOCKS5 프록시와 기본 작업에 적합합니다. 구성 파일 /etc/redsocks.conf:
base {
log_debug = off;
log_info = on;
log = "file:/var/log/redsocks.log";
daemon = on;
redirector = tproxy;
}
redsocks {
local_ip = 127.0.0.1;
local_port = 7893;
// SOCKS5 프록시의 주소
ip = 185.220.101.50;
port = 1080;
type = socks5;
// 프록시가 인증을 요구하는 경우:
login = "your_login";
password = "your_password";
}
옵션 2: sing-box (권장 — TCP + UDP)
sing-box는 TPROXY를 네이티브로 지원하며 SOCKS5, HTTP, Shadowsocks, VLESS, Trojan과 같은 대부분의 프록시 유형과 함께 작동합니다. 구성 예제 /etc/sing-box/config.json:
{
"inbounds": [
{
"type": "tproxy",
"listen": "127.0.0.1",
"listen_port": 7893,
"tcp_fast_open": false,
"udp_fragment": true,
"sniff": true
}
],
"outbounds": [
{
"type": "socks",
"tag": "proxy-out",
"server": "185.220.101.50",
"server_port": 1080,
"version": "5",
"username": "your_login",
"password": "your_password"
},
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"rules": [
{
"geoip": ["private"],
"outbound": "direct"
}
],
"final": "proxy-out"
}
}
sing-box를 실행하고 자동 시작에 추가하십시오:
/etc/init.d/sing-box enable
/etc/init.d/sing-box start
옵션 3: mihomo / Clash Meta
mihomo는 확장된 기능을 가진 Clash의 포크입니다. tproxy-port 섹션에 가로챌 포트를 지정하십시오:
mixed-port: 7890
tproxy-port: 7893
allow-lan: false
mode: rule
log-level: info
proxies:
- name: "my-socks5"
type: socks5
server: 185.220.101.50
port: 1080
username: your_login
password: your_password
udp: true
proxy-groups:
- name: "PROXY"
type: select
proxies:
- my-socks5
rules:
- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- MATCH,PROXY
DNS 유출 방지
올바른 DNS 설정 없이 투명 프록시는 심각한 취약점이 될 수 있습니다. DNS 요청이 프록시가 아닌 공급자를 통해 직접 전송되면, IP 주소를 변경하더라도 실제 위치가 노출됩니다. 이는 익명성이나 지리적 변경이 중요한 작업에 치명적입니다.
방법 1: TPROXY를 통한 DNS 가로채기
포트 53에서 UDP 트래픽을 가로채기 위한 규칙을 추가하십시오:
# 네트워크 장치의 DNS 요청 가로채기
iptables -t mangle -A TPROXY_RULES -p udp --dport 53 \
-j TPROXY --on-port 7893 --on-ip 127.0.0.1 --tproxy-mark 1
방법 2: sing-box / mihomo를 통한 DNS 처리
sing-box와 mihomo는 DNS 요청을 자체적으로 처리하고 프록시를 통해 전송할 수 있습니다. sing-box 구성에 DNS 섹션을 추가하십시오:
"dns": {
"servers": [
{
"tag": "remote",
"address": "8.8.8.8",
"detour": "proxy-out"
},
{
"tag": "local",
"address": "192.168.1.1",
"detour": "direct"
}
],
"rules": [
{
"geoip": ["private"],
"server": "local"
}
],
"final": "remote",
"independent_cache": true
}
방법 3: dnsmasq를 통한 프록시를 통한 업스트림
sing-box/mihomo를 사용하지 않는 경우, dnsmasq(기본 OpenWrt DNS 서버)를 설정하여 요청을 암호화된 DNS 서버로 전달하도록 하십시오. /etc/dnsmasq.conf 파일에서:
# 공급자의 DNS 사용 비활성화
no-resolv
# 로컬 리졸버를 통해 DoH/DoT 사용
server=127.0.0.1#5335
# 장치가 외부 DNS를 직접 사용하지 못하도록 차단
# (직접 DNS 요청을 차단하기 위한 iptables 규칙)
# iptables -t nat -A PREROUTING -p udp --dport 53 ! -d 192.168.1.1 -j DNAT --to 192.168.1.1
검사 및 디버깅
설정 후 투명 프록시의 작동 여부를 반드시 확인하십시오. 다음은 단계별 체크리스트입니다.
단계 1: iptables 규칙 확인
# TPROXY_RULES 체인 보기
iptables -t mangle -L TPROXY_RULES -v -n
# 100번 라우팅 테이블 확인
ip rule show
ip route show table 100
단계 2: 프록시 클라이언트가 포트를 수신 대기하는지 확인
ss -tlnp | grep 7893
# 또는
netstat -tlnp | grep 7893
127.0.0.1:7893에서 수신 대기하는 sing-box, mihomo 또는 redsocks 프로세스를 확인해야 합니다.
단계 3: 클라이언트 장치에서 IP 확인
네트워크의 어떤 장치에서든 라우터에 연결하고 브라우저에서 ifconfig.me 또는 2ip.ru를 엽니다. 표시되는 IP는 실제 제공자의 IP가 아닌 프록시 서버의 IP와 일치해야 합니다.
단계 4: DNS 유출 확인
dnsleaktest.com로 이동하여 확장 테스트를 수행합니다. 결과의 DNS 서버는 귀하의 프록시 제공자 또는 선택한 DoH 서버에 속해야 하며, 귀하의 인터넷 제공자에 속해서는 안 됩니다.
일반적인 문제 및 해결 방법
| 증상 | 원인 | 해결 방법 |
|---|---|---|
| 인터넷이 전혀 작동하지 않음 | 프록시 클라이언트가 실행되지 않음 | 서비스 상태 및 클라이언트 로그를 확인하십시오 |
| IP가 변경되지 않음 | iptables 규칙이 적용되지 않음 | iptables -t mangle -L -v를 확인하십시오 |
| UDP 작동하지 않음 | redsocks가 UDP를 지원하지 않음 | sing-box 또는 mihomo로 전환하십시오 |
| 라우팅 루프 | 프록시 클라이언트의 트래픽도 가로채짐 | 프록시 클라이언트의 UID 또는 cgroup을 규칙에서 제외하십시오 |
| TPROXY 대상 오류 | 커널 모듈이 로드되지 않음 | modprobe xt_TPROXY를 실행하십시오 |
TPROXY에 적합한 프록시 유형
프록시 유형의 선택은 결과에 중대한 영향을 미칩니다. 라우터에서 투명 프록시를 위해서는 모든 옵션이 적합한 것은 아니며, 프로토콜, 연결 안정성 및 작업을 고려해야 합니다.
SOCKS5 프록시
TPROXY에 가장 보편적인 옵션입니다. TCP 및 UDP를 지원합니다 (sing-box/mihomo 사용 시). 대부분의 작업에 적합합니다: 지리적 차단 우회, 전체 네트워크의 IP 변경, 마켓플레이스 작업. 데이터 센터 프록시는 SOCKS5 형식으로 높은 속도와 안정성을 제공하며, 속도가 우선인 경우 최적의 선택입니다.
레지던트 프록시
레지던트 프록시는 실제 가정 사용자의 IP 주소를 사용합니다. 라우터에서 TPROXY를 통해 라우팅할 경우, 이는 네트워크의 모든 트래픽이 필요한 국가의 일반 가정 인터넷 사용자의 트래픽처럼 보이게 합니다. 다음과 같은 작업에 이상적입니다:
- 해외 마켓플레이스(Amazon, eBay, Zalando)에서 가격 모니터링
- 다양한 지역에서 광고 테스트
- 데이터 센터 IP를 적극적으로 차단하는 플랫폼과 작업
- 실제 사용자처럼 최대한 위장해야 하는 작업
모바일 프록시
모바일 프록시는 이동통신 사업자(4G/5G)의 IP를 통해 작동합니다. 이들은 플랫폼으로부터 가장 높은 신뢰도를 가지고 있으며 — Facebook, Instagram, TikTok은 모바일 IP를 거의 차단하지 않습니다. 이는 하나의 주소 뒤에 수천 명의 실제 사용자가 있을 수 있기 때문입니다. 라우터에서 TPROXY를 통해 사용하면 네트워크의 모든 트래픽이 모바일 IP를 받게 되며, 이는 다음과 같은 작업에 중요합니다:
- Facebook Ads 및 TikTok Ads를 통한 트래픽 중재
- 소셜 미디어 계정의 대량 생성
- 안티 디텍트 브라우저(Dolphin Anty, AdsPower, GoLogin)와 단일 게이트웨이를 통한 작업
| 프록시 유형 | 속도 | 플랫폼 신뢰도 | 최고의 시나리오 |
|---|---|---|---|
| 데이터 센터 | ⚡ 높음 | ★★☆☆☆ | 파싱, 가격 모니터링 |
| 레지던트 | ⚡⚡ 중간 | ★★★★☆ | 지리적 테스트, 전자상거래 |
| 모바일 | ⚡ 중간 | ★★★★★ | 소셜 미디어, 트래픽 중재 |
결론
OpenWrt에서 TPROXY를 통한 투명 프록시는 전체 네트워크의 트래픽을 중앙 집중식으로 관리하는 강력한 도구입니다. 이 접근 방식의 주요 장점은 각 장치에서 프록시를 개별적으로 설정할 필요가 없고, TCP 및 UDP 트래픽을 모두 지원하며, 구성은 가정용 사용부터 기업 인프라까지 다양한 작업에 유연하게 확장될 수 있다는 것입니다.
우리가 다룬 주요 단계는 OpenWrt 커널에서 TPROXY 지원 확인, 필요한 패키지 설치, 올바른 fwmark를 가진 iptables/nftables 규칙 설정, 프록시 클라이언트(redsocks, sing-box 또는 mihomo) 구성 및 DNS 유출 방지입니다. 이러한 각 단계는 중요하며, 하나라도 пропуск하면 잘못된 작동이나 실제 IP 유출로 이어질 수 있습니다.
귀하의 작업이 전체 네트워크의 트래픽을 최대한 신뢰할 수 있는 플랫폼(Facebook, Instagram, TikTok, 해외 마켓플레이스)을 통해 프록시로 라우팅하는 것이라면, 레지던트 프록시를 사용하는 것이 좋습니다 — 이는 필요한 국가의 실제 가정 IP를 제공하며, 라우터에서 투명 프록시를 통해 작업할 때 차단 위험을 최소화합니다.
```