보조 라우터 배포는 데스크톱 클라이언트를 라우터에 옮겨 설치하는 것과 다릅니다. 게이트웨이, 코어 인바운드, 방화벽, DNS, 반환 경로를 함께 설정해야 합니다. Linux 터미널을 사용할 수 있는 독자를 위해 IPv4 테스트 네트워크를 예로 들어 배포 순서를 설명합니다. 먼저 Xray의 아웃바운드를 확인하고, 한 대의 기기를 연결한 뒤, 투명 프록시 적용 범위를 넓혀 보세요. 설정 예시는 단계별 점검을 위한 것으로, 복사만 하면 전체 네트워크를 제어하는 스크립트가 아닙니다.
1. 메인 라우터와 보조 라우터의 트래픽 경로
메인 라우터는 인터넷 연결을 담당하며 보통 PPPoE 접속, 주소 할당, NAT를 처리합니다. 보조 라우터는 기존 LAN에 추가하는 전달 장치입니다. 선택한 기기가 트래픽을 먼저 보조 라우터로 보내면, 보조 라우터가 직접 연결할지 프록시를 통해 내보낼지 결정합니다. 보조 라우터를 네트워크에 연결하는 것만으로 다른 기기의 트래픽이 자동으로 전달되지는 않습니다. 기기의 게이트웨이, DHCP 옵션 또는 메인 라우터의 정책 라우팅으로 트래픽 경로를 지정해야 합니다.
이 글에서는 메인 라우터를 192.168.10.1/24, Linux 미니 PC를 192.168.10.2/24, 테스트 PC를 192.168.10.100/24로 설정합니다. 이 주소는 설명을 위한 사설 IP이므로 실제 배포 환경의 서브넷에 맞게 바꾸세요. DHCP가 같은 주소를 동적으로 할당하지 않도록 메인 라우터에서 미니 PC의 주소를 예약해야 합니다.
단일 기기만 보조 라우터로 연결
권장메인 라우터 설정은 그대로 두고 테스트 PC의 기본 게이트웨이만 192.168.10.2로 변경합니다. 미니 PC의 기본 게이트웨이는 계속 192.168.10.1을 사용합니다. 적용 범위가 작아 인터넷이 끊겨도 쉽게 복구할 수 있습니다.
적합한 경우: 첫 설정 테스트, 기존 가정용 네트워크, 기기별 단계적 전환
메인 라우터에서 직접 실행
메인 라우터에서 Xray를 실행하고 같은 기기에서 트래픽을 전달합니다. 경로를 한곳에서 관리할 수 있지만, CPU 아키텍처, 사용 가능한 메모리와 저장 공간, 방화벽 연동 방식을 확인해야 합니다.
적합한 경우: 라우터 시스템을 직접 관리하고 방화벽을 유지 관리할 수 있는 사용자
이중 LAN 포트와 별도 서브넷
미니 PC의 상단 연결은 메인 라우터에, 하단 연결은 별도 서브넷에 둡니다. 하단 네트워크의 기기는 모두 미니 PC를 게이트웨이로 사용합니다. 반환 경로가 명확해지는 대신 주소 할당, 패킷 전달, 외부 연결용 NAT를 별도로 설정해야 합니다.
적합한 경우: 분리된 테스트 네트워크, 상시 게이트웨이 구성
결론: 테스트 PC 한 대부터 시작
첫 배포부터 전체 네트워크의 DHCP 게이트웨이를 바꾸지 마세요. 먼저 192.168.10.100의 트래픽만 보조 라우터를 거치게 하고, 일반 웹 접속, DNS, LAN 접근이 모두 정상인지 확인한 뒤 다른 기기를 추가하세요.
2. Xray 직접 실행 전 환경 점검
V2Ray는 이런 유형의 프록시 도구를 통칭하는 말로 자주 쓰이지만, Xray와 V2Fly는 서로 다른 코어 프로젝트이므로 설정 기능을 같은 것으로 보면 안 됩니다. 이 글에서는 Xray를 사용합니다. v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 구독 관리나 클라이언트 UI 설정만으로 Linux의 투명 프록시가 구성되는 것은 아닙니다.
라우터에서는 먼저 CPU 아키텍처와 시스템 C 라이브러리 요구 사항을 확인하세요. Linux 미니 PC에서는 서비스 관리자, 방화벽 구성, 바이너리 경로를 점검해야 합니다. 한 아키텍처용 실행 파일을 다른 아키텍처 기기에 그대로 복사해서는 안 됩니다. 기존 관리 스크립트가 있는 기기에 별도의 규칙 체계를 추가하는 것도 피하세요.
# 아키텍처, 커널 및 현재 네트워크 상태 확인
uname -m
uname -r
ip -br address
ip route
timedatectl status
# Xray가 이 경로에 설치되어 있다고 가정하는 명령
/usr/local/bin/xray version
/usr/local/bin/xray run -test -config /etc/xray/config.json
# 이 글의 예시에서 사용하는 포트 확인
ss -lntup | grep -E ':(53|10808|12345)\b'이 숫자는 설정 예시이며 성능 측정 결과가 아닙니다. 포트가 이미 사용 중이라면 코어 설정과 방화벽 규칙을 함께 변경해야 합니다. 시스템 시간도 정확하게 유지하세요. TLS 핸드셰이크는 인증서 유효 기간을 확인하므로, 시간이 잘못되면 단순한 라우팅 문제가 아니라 연결 실패로 나타날 수 있습니다.
3. 5단계로 테스트 기기 연결
작업은 애플리케이션 계층에서 네트워크 계층 순서로 진행하세요. 먼저 코어가 외부로 연결되는지 확인하고, 다음으로 기기 트래픽이 보조 라우터에 도달하는지 확인한 뒤, 투명 프록시 인바운드를 설정합니다. 게이트웨이, DNS, 방화벽을 한꺼번에 바꾸면 문제가 생겼을 때 어느 단계에서 실패했는지 파악하기 어렵습니다.
-
기존 설정 기록
테스트 PC의 기존 IP 주소, 게이트웨이, DNS를 기록하고 미니 PC에서
ip route출력을 저장한 뒤/etc/xray/config.json을 백업합니다. 원격으로 관리한다면 로컬 관리 경로를 하나 남겨 두세요. -
아웃바운드 연결 확인
/etc/xray/config.json에서 127.0.0.1:10808에만 바인딩하는 SOCKS 인바운드와 확인된 프록시 아웃바운드를 설정합니다. 먼저 설정을 검증한 다음 미니 PC에서 대상 주소로 직접 요청을 보내세요. -
게이트웨이 설정
Windows 테스트 PC에서 「설정」→「네트워크 및 인터넷」→ 현재 네트워크 어댑터 속성 →「IP 할당」→「편집」으로 이동해 수동 IPv4를 선택합니다. 예시 주소는 192.168.10.100, 서브넷 마스크는 255.255.255.0, 게이트웨이는 192.168.10.2입니다. Windows 버전에 따라 항목 위치가 조금 다를 수 있습니다.
-
TCP 연결
12345 투명 프록시 인바운드를 추가하고, 방화벽 규칙은 테스트 PC의 출발지 주소와 실제 LAN 인터페이스에만 적용합니다. 먼저 TCP만 처리하고, 내부망 목적지 주소는 직접 연결로 유지하세요. UDP와 기기 자체 트래픽까지 동시에 가로채지 마세요.
-
DNS 연결
미니 PC의 DNS 서비스가 질의에 정상적으로 응답하는지 확인한 뒤 테스트 PC의 DNS를 192.168.10.2로 변경합니다. UDP 53, TCP 53, 도메인 조회 결과를 확인하고, 마지막으로 네트워크 어댑터를 다시 연결해 설정이 적용됐는지 점검하세요.
미니 PC의 기본 경로는 메인 라우터를 가리켜야 하며 자기 자신을 가리켜서는 안 됩니다. 단일 네트워크 인터페이스와 동일 서브넷을 사용하는 구성에서는 직접 전달되는 패킷이 메인 라우터를 통해 곧바로 기기로 돌아가 비대칭 경로가 생길 수 있습니다. 제한적인 SNAT를 적용할지는 반환 경로와 상태 기반 방화벽 요구 사항을 고려해 결정하세요. SNAT는 원래 기기의 주소를 숨기므로 무조건 켜도 되는 만능 해결책이 아닙니다.
4. 투명 프록시 인바운드와 방화벽 연동
투명 프록시는 두 부분으로 작동합니다. 방화벽은 조건에 맞는 패킷을 로컬 인바운드로 보내고, Xray는 원래 목적지 주소를 읽어 아웃바운드를 선택합니다. 포트를 열어 두는 것만으로 기기 트래픽이 자동으로 가로채지는 않습니다. 대응하는 인바운드 없이 리디렉션 규칙만 설정해도 프록시로 사용할 수 없습니다.
| 연결 방식 | 핵심 동작 | 적용 범위와 조건 |
|---|---|---|
| 명시적 SOCKS 프록시 | 애플리케이션이 로컬 인바운드에 직접 연결 | 먼저 아웃바운드를 확인할 때 적합하며, 투명한 트래픽 전달은 필요하지 않습니다 |
| TCP REDIRECT | NAT 리디렉션과 원래 목적지 주소 읽기 | TCP를 단계별로 테스트할 때 적합하며, UDP까지 처리한다는 뜻은 아닙니다 |
| TPROXY | 투명 소켓, 패킷 마크, 정책 라우팅 | TCP와 UDP를 처리할 수 있지만 커널 및 방화벽 설정이 함께 필요합니다 |
아래는 직접 연결을 확인하기 위한 최소 설정입니다. 로컬 SOCKS와 TCP 투명 프록시 인바운드를 제공하지만, 유일한 아웃바운드는 freedom이므로 모든 요청은 계속 직접 연결됩니다. 프록시 노드, DNS 서비스, 방화벽 규칙은 포함되어 있지 않습니다. 이 설정을 완성된 프록시 구성으로 오해하지 마세요.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": false
}
},
{
"tag": "lan-tcp",
"listen": "0.0.0.0",
"port": 12345,
"protocol": "dokodemo-door",
"settings": {
"network": "tcp",
"followRedirect": true
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}- 인바운드 분리: 12345는 LAN에서 리디렉션된 트래픽을 받기 위해 모든 IPv4 인터페이스에서 수신 대기합니다. 방화벽에서 신뢰할 수 있는 출발지만 허용하고 WAN 접근은 차단해야 합니다. 10808은 계속 로컬에서만 접근할 수 있도록 유지하세요.
- 목적지 주소 제외: 일반 프록시 리디렉션에서 기기의 관리 주소, LAN 서브넷, 루프백, 링크 로컬, 멀티캐스트, 브로드캐스트 주소를 제외해야 합니다. 실제 사용하는 다른 내부 네트워크도 명시적으로 제외하세요.
- 프록시 서버 제외: 프록시 아웃바운드가 연결되는 서버 주소는 계속 접근 가능해야 합니다. 나중에 기기 자체의 트래픽까지 전달한다면, Xray 아웃바운드를 프로세스 ID나 마크로 제외해 프록시가 다시 자신에게 연결되는 상황을 막아야 합니다.
- 적용 범위 제한: 첫 단계에서는 LAN 인바운드 인터페이스와 192.168.10.100만 대상으로 지정하세요. 처음부터 모든 출발지, 모든 프로토콜, OUTPUT 체인을 전부 처리하지 마세요.
TPROXY는 REDIRECT 이름만 바꾸면 되는 기능이 아닙니다. 일반적으로 패킷 마크로 전용 라우팅 테이블을 선택하고, 해당 테이블에 로컬 전달 경로를 설정해야 합니다. 코어 인바운드에서도 대응하는 투명 소켓 옵션을 활성화해야 합니다. 기존 시스템 규칙과 충돌하지 않도록 마크 값, 라우팅 테이블 번호, 방화벽 우선순위를 정하세요. 이 글에서는 기기 환경을 확인하지 않고 그대로 적용할 수 있는 전체 네트워크용 규칙 스크립트를 제공하지 않습니다.
5. DNS 전달은 별도로 검증
게이트웨이와 DNS는 별개의 설정입니다. 기기의 게이트웨이를 보조 라우터로 바꿔도 보조 라우터를 통해 도메인을 조회한다는 보장은 없습니다. 기기가 계속 메인 라우터에 질의하거나 브라우저의 암호화 DNS를 사용할 수 있습니다. 기존 포트 53 트래픽을 리디렉션해도 HTTPS 기반 DNS 요청까지 자동으로 처리되지는 않습니다.
먼저 미니 PC에 신뢰할 수 있는 LAN에서만 접근 가능한 DNS 리졸버를 준비하고, 상위 DNS로 보낼 경로를 명확히 지정하세요. Xray 설정의 dns 필드는 코어 내부의 DNS 조회에 사용되며, LAN 주소에서 사용할 수 있는 일반 DNS 서비스를 제공하는 것은 아닙니다. 코어의 DNS 조회, 기기의 DNS 질의, 라우팅 규칙을 각각 확인해야 합니다.
| 확인 항목 | 검증 방법 | 확인할 내용 |
|---|---|---|
| 기기의 DNS 서버 주소 | 네트워크 어댑터에 설정된 DNS 주소 확인 | 기본 게이트웨이만 변경한 것은 아닌지 확인 |
| UDP 질의 | dig @192.168.10.2 example.com A | 서비스 수신 상태, 출발지 권한, 상위 DNS 접근 여부 확인 |
| TCP 질의 | dig +tcp @192.168.10.2 example.com A | TCP 53 처리가 빠지지 않았는지 확인 |
| IPv6 DNS 조회 | dig @192.168.10.2 example.com AAAA | IPv6 트래픽 경로가 예상대로 설정됐는지 확인 |
투명 프록시 인바운드에 도착하는 트래픽에는 대상 IP만 포함되는 경우가 많습니다. 도메인별로 트래픽을 분기하려면 도메인 정보를 어디서 가져올지 고려해야 합니다. 스니핑으로 일부 HTTP 또는 TLS 트래픽에서 정보를 얻을 수 있지만 모든 연결에서 가능한 것은 아닙니다. 스니핑을 사용해도 브라우저의 DNS 동작이 통합되는 것은 아닙니다. IP 규칙과 도메인 규칙은 실제 인바운드가 처리할 수 있는 정보를 바탕으로 설계하세요.
6. 패킷 전달, 반환 경로, 시작 순서
투명 프록시 인바운드가 가로채지 않은 패킷도 보조 라우터에서 정상적으로 전달되어야 합니다. Linux의 IPv4 포워딩 설정, FORWARD 허용 규칙, 상위 라우터의 반환 경로가 모두 맞아야 합니다. 포워딩을 활성화했다고 모든 패킷이 허용되는 것은 아닙니다. 방화벽을 전체 허용으로 바꾸지 마세요.
# IPv4 포워딩이 활성화되어 있는지 확인
sysctl net.ipv4.ip_forward
# 역방향 경로 필터링 설정 확인; 변경 여부는 실제 네트워크 구성에 따라 판단
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
# 규칙과 정책 라우팅 확인; 원격 세션에서 규칙을 바로 삭제하지 마세요
sudo nft list ruleset
ip rule show
ip route show table all
# xray.service가 생성된 systemd 환경에서만 사용
systemctl status xray --no-pager
journalctl -u xray -n 80 --no-pager엄격한 역방향 경로 필터링은 정책 라우팅이나 비대칭 반환 경로에서 패킷을 버릴 수 있지만, 연결이 끊겼다고 전역 설정을 무조건 해제해서는 안 됩니다. 먼저 패킷이 어느 인터페이스로 들어오는지, 역방향 경로가 어디를 가리키는지 확인한 다음 관련 인터페이스에 적절한 정책을 적용하세요. nftables 또는 iptables를 사용할 때는 시스템의 기존 관리 방식을 따르고, 두 가지 규칙 관리 방식이 서로 덮어쓰지 않도록 하세요.
- 시작 순서: 코어가 실행되려면 네트워크에 접근할 수 있어야 합니다. DNS 상위 서버로 가는 트래픽이 프록시를 사용한다면, 프록시 서버 도메인 조회가 아직 시작되지 않은 프록시에 의존하지 않도록 해야 합니다.
- 설정 영구 적용: 명령줄에서 설정한 포워딩과 방화벽 규칙은 재부팅 후 사라질 수 있습니다. 터미널 기록에만 남기지 말고 시스템 설정 파일과 기존 방화벽 서비스에 저장하세요.
- 장애 시 동작: 코어가 중지된 뒤에도 리디렉션 규칙이 남아 있으면 트래픽이 수신 대기 중인 서비스가 없는 포트로 전달될 수 있습니다. 장애 시 인터넷 연결을 차단할지, 트래픽 전달을 해제해 직접 연결로 복구할지 미리 정해야 합니다.
- 리소스 확인: 웹페이지를 한 번 여는 속도만 보지 말고 CPU, 메모리, 연결 수, 로그 증가량을 확인하세요. 라우터의 저장 공간은 제한적이므로 상세 접속 로그를 장기간 보관하지 않는 편이 좋습니다.
7. 자주 발생하는 문제와 복구 순서
문제를 진단할 때는 테스트 기기 한 대, 대상 하나, 프로토콜 하나로 범위를 좁히세요. 명시적 SOCKS 연결을 먼저 확인하고, 투명 TCP, DNS와 UDP 순서로 점검합니다. 모든 시간 초과를 노드 문제로 단정하지 마세요. 패킷이 Xray에 도달하지 않았을 수도 있고, 코어에서 나간 뒤 반환 패킷이 방화벽에서 차단됐을 수도 있습니다.
| 증상 | 우선 확인할 항목 | 조치 방향 |
|---|---|---|
| 미니 PC의 SOCKS 연결도 실패 | 아웃바운드 매개변수, 시스템 시간, 서비스 로그 | 먼저 애플리케이션 계층 문제를 해결하고 기기의 게이트웨이는 변경하지 마세요 |
| SOCKS는 정상인데 투명 프록시 연결 실패 | 출발지 매칭, 인바운드 수신 상태, 규칙 카운터 | 패킷이 12345 인바운드까지 도달하는지 확인 |
| IP 주소로는 연결되지만 도메인은 접속 불가 | DNS 수신 상태와 상위 서버, TCP/UDP 53 | DNS 서비스를 따로 검증하고 노드를 계속 바꾸지 마세요 |
| 웹은 되지만 UDP를 사용하는 앱은 실패 | TCP만 전달하도록 설정했는지 확인 | UDP 구성을 추가한 뒤 다시 확인하세요. TCP 성공을 UDP까지 정상이라는 근거로 삼지 마세요 |
| 일부 연결이 보조 라우터를 우회 | IPv6 라우팅, 앱 자체 프록시 설정, DNS | 듀얼 스택의 전체 경로와 앱 동작 확인 |
| 재부팅 후 전체 네트워크 연결이 끊김 | 주소 변경, 서비스 시작 상태, 규칙 영구 적용 여부 | 주소, 서비스, 규칙 순서로 복구 |
경로를 확인해야 한다면 미니 PC에서 tcpdump -ni eth0 host 192.168.10.100을 사용할 수 있습니다. 여기서 eth0은 실제 인터페이스 이름으로 바꿔야 합니다. 패킷 캡처에는 도메인과 통신 메타데이터가 포함될 수 있으므로 범위를 좁혀 짧게 실행하고, 공유하기 전에 민감한 정보를 가리세요. 브라우저 오류만 확인하는 것보다 규칙 카운터와 인바운드 로그를 함께 보면 끊긴 지점을 더 쉽게 찾을 수 있습니다.
결론: 명확한 원복 경로 마련
점검이 끝나기 전에는 전체 네트워크로 적용 범위를 넓히지 마세요. 문제가 생기면 먼저 테스트 PC의 게이트웨이를 192.168.10.1로 되돌리고 기존 DNS를 복원합니다. 그다음 이번에 추가한 규칙만 취소하고 방화벽 전체 규칙을 지우지 마세요. 메인 라우터를 통한 직접 연결이 정상인지 확인한 뒤 보조 라우터 설정을 단계별로 다시 적용하세요.
보조 라우터의 핵심은 지정한 기기의 트래픽을 한곳에서 처리하는 것이지 네트워크 설정 작업을 줄이는 것이 아닙니다. 안정적인 구성을 위해서는 인바운드, 아웃바운드, DNS, 반환 경로, 재부팅 후 동작을 모두 명확히 해야 합니다. PC 한 대나 Android 기기 한 대에서만 프록시를 사용한다면, 먼저 클라이언트에서 노드와 프로토콜을 확인하는 편이 네트워크 전체를 제어하는 것보다 문제를 진단하기 쉽습니다. 기본 개념은 용어 빠르게 보기에서, 연결 문제는 고급 사용법의 연결 문제 해결에서 확인할 수 있습니다.