라우터 배포의 핵심은 데스크톱 설정을 그대로 옮기는 것이 아니라 게이트웨이, 트래픽 가로채기, DNS, 코어의 아웃바운드를 하나의 경로로 연결하는 데 있습니다. Linux 또는 OpenWrt 장비를 프록시 게이트웨이로 사용하려는 분들을 위해 메인 라우터와 보조 라우터의 역할을 구분하고, 단일 기기 테스트 절차와 투명 프록시의 범위, 하드웨어 점검 항목, 문제 발생 시 복구 방법을 안내합니다.
1. 배포 위치: 메인 라우터와 보조 라우터의 역할
메인 라우터는 보통 인터넷 연결, DHCP 주소 할당, NAT, 방화벽을 담당합니다. 여기에 코어를 설치하면 전체 트래픽이 지나가는 지점에서 처리할 수 있지만, 프록시 서비스 업데이트나 규칙 설정 오류, 리소스 부족이 발생하면 집 안의 모든 기기에 영향을 줄 수 있습니다. 보조 라우터는 별도의 트래픽 전달 장치입니다. 먼저 일부 기기만 게이트웨이로 사용하게 하면 테스트 범위를 제한할 수 있습니다.
독립형 보조 라우터로 시험 운영
권장메인 라우터의 기존 인터넷 연결과 주소 할당은 그대로 두고, 테스트할 기기의 게이트웨이만 변경합니다. 문제가 생기면 해당 기기의 게이트웨이를 원래대로 돌리면 되므로 전체 네트워크의 전달 규칙을 바꾸는 것보다 원인 파악과 복구가 쉽습니다.
적합한 경우: 첫 배포이거나 가정용 네트워크에서 기기별로 검증하려는 경우
메인 라우터에서 직접 실행
한 장비에서 인터넷 연결, 방화벽, 프록시를 통합 관리합니다. 규칙을 한곳에서 관리할 수 있지만 CPU, 메모리, 저장 공간에 여유가 있는지 확인하고 로컬 관리 경로도 확보해야 합니다.
적합한 경우: 방화벽에 익숙하고 네트워크를 통합 관리하려는 경우
기기별 클라이언트 사용
데스크톱에서는 v2rayN을 사용하고, 안드로이드에서는 노드 구성에 따라 v2rayNG 또는 v2flyNG를 선택합니다. 로컬 네트워크의 게이트웨이를 바꿀 필요가 없으며, 라우터에 배포하기 전에 노드가 작동하는지 확인하는 기준으로 적합합니다.
적합한 경우: 프록시가 필요한 기기가 몇 대뿐이거나 네트워크 변경을 미루려는 경우
이 문서에서는 단일 이더넷 포트를 사용하는 보조 라우터를 예로 듭니다. 메인 라우터는 192.168.10.1/24, 보조 라우터는 192.168.10.2/24, 테스트 기기는 192.168.10.100/24입니다. 실제 네트워크 대역에 맞게 주소를 바꾸고, 보조 라우터 주소는 DHCP 동적 할당 범위에서 제외하세요. 이 주소는 설정 예시이며 기기의 출고 시 기본값이 아닙니다.
테스트 기기 192.168.10.100
기본 게이트웨이 → 보조 라우터 192.168.10.2
├─ 직접 연결 아웃바운드 → 메인 라우터 192.168.10.1 → 인터넷
└─ 프록시 아웃바운드 → 메인 라우터 192.168.10.1 → 원격 노드
보조 라우터 자체의 기본 게이트웨이: 192.168.10.1
메인 라우터 자체의 기본 게이트웨이: 인터넷 서비스 제공업체 상위 게이트웨이2. 코어 선택: 프로토콜, 아키텍처, 설정 형식 함께 확인하기
Xray와 V2Fly는 각각 독립적으로 실행되는 프록시 코어이며 라우터 운영체제는 아닙니다. v2rayN, v2rayNG, v2flyNG는 클라이언트 인터페이스입니다. 이 가운데 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 라우터 배포 시에는 데스크톱 클라이언트가 아니라 해당 Linux 프로그램, 설정 파일, 서비스 실행 방식을 확인해야 합니다.
- 프로세서 아키텍처 확인:
uname -m을 실행한 뒤 펌웨어의 패키지 아키텍처와 비트 수, 실행 환경을 확인하세요. 기기 사양에 “ARM”이라고 적혀 있다는 이유만으로 프로그램을 선택해서는 안 됩니다. - 노드 프로토콜 확인: VMess 또는 VLESS, 전송 방식, TLS 매개변수, 서버 요구 사항을 각각 확인하세요. 노드가 REALITY를 사용하는 경우 해당 설정을 명시적으로 지원하는 Xray 빌드를 선택해야 합니다. 두 코어의 설정 항목을 서로 바꿔 쓸 수 있다고 가정하면 안 됩니다.
- 설정 버전 확인: V2Fly는 버전에 따라 설정 형식이 다를 수 있으며 Xray의 설정 항목도 계속 변경됩니다. 기기에 설치된 버전에 맞춰 설정을 확인하고, 다른 코어의 JSON 파일 전체를 그대로 복사하지 마세요.
- 구독 처리 방식 확인: 구독 URL은 코어가 공통으로 자동 업데이트해 주는 설정이 아닙니다. 일반적으로 관리 패널이나 스크립트가 구독을 파싱하고 설정을 생성한 뒤 업데이트와 재시작을 처리합니다. 코어만 직접 배포한다면 이 과정을 별도로 구현해야 합니다.
3. 투명 프록시: 포트 수신 외에 정책 라우팅도 필요합니다
명시적 프록시는 앱이 HTTP 또는 SOCKS 수신 포트로 연결을 보내는 방식입니다. 반면 투명 프록시는 게이트웨이가 전달 경로에서 연결을 가로채 코어로 넘깁니다. 프로그램이 포트 하나를 열어 두는 것만으로 로컬 네트워크의 트래픽이 자동으로 전환되거나 응답 경로가 만들어지지는 않습니다. Linux 방화벽 규칙, 정책 라우팅, 코어의 인바운드 설정이 서로 맞아야 합니다.
위 포트와 라우팅 테이블 번호는 구성 예시이며 관리 화면의 기본값을 의미하지 않습니다. 라우팅 테이블 번호 100을 사용하기 전에 다른 서비스가 이미 사용 중인지 확인하세요. 투명 인바운드에서는 선택한 코어에 필요한 투명 소켓 옵션을 활성화하고, 방화벽이 트래픽을 전달하는 방식과 일치시켜야 합니다.
| 가로채기 방식 | 주요 작동 방식 | 배포 시 유의 사항 |
|---|---|---|
| REDIRECT | 연결을 로컬 수신 포트로 리디렉션 | 주로 TCP에 사용합니다. TCP 설정을 UDP에 그대로 적용할 수는 없습니다. |
| TPROXY | 투명 소켓으로 트래픽을 받은 뒤 마크와 정책 라우팅을 이용해 로컬 장치로 전달 | TCP/UDP에 사용할 수 있습니다. 펌웨어의 커널 모듈과 해당 방화벽 지원이 필요합니다. |
| 명시적 SOCKS 프록시 | 앱이 프록시 수신 주소에 직접 연결 | 코어를 먼저 검증할 때 적합합니다. 앱이 프록시를 지원하고 올바르게 사용해야 합니다. |
firewall4를 사용하는 OpenWrt 환경에서는 보통 nftables로 규칙을 관리합니다. 이전 자료의 iptables 명령이 그대로 작동하지 않을 수 있습니다. TPROXY는 일반적으로 트래픽에 마크를 지정하고 ip rule로 전용 라우팅 테이블을 선택한 다음, 로컬 라우팅을 통해 투명 소켓으로 전달하는 방식입니다. 마크 값과 마스크는 기존 멀티 WAN 및 정책 라우팅 서비스와 겹치지 않도록 해야 합니다.
- 루프백, 멀티캐스트, 브로드캐스트, 로컬 네트워크 관리 대역, 보조 라우터에서 직접 연결해야 하는 트래픽은 먼저 허용하세요.
- 노드 서버 주소와 코어의 자체 아웃바운드 연결은 제외해 “프록시 연결이 다시 프록시로 들어가는” 루프를 방지하세요.
- 로컬 네트워크에서 전달되는 트래픽과 라우터 자체가 시작한 연결을 구분해 처리하세요. PREROUTING 규칙만으로 라우터 자체의 모든 연결이 자동으로 전환되지는 않습니다.
- 소프트웨어 또는 하드웨어 트래픽 오프로딩이 예상한 규칙 경로를 우회하는지 확인하세요. 디버깅하는 동안에는 관련 오프로딩을 끄고 비교 테스트를 먼저 진행하세요.
4. 게이트웨이와 DNS: 기기 한 대부터 변경한 뒤 범위를 넓히세요
보조 라우터 설정에 공통으로 적용되는 단일 화면은 없습니다. 아래 내용은 일반적인 OpenWrt LuCI 메뉴를 예로 들며, 메뉴 번역은 버전에 따라 달라질 수 있습니다. 작업 전에 설정을 내보내고 메인 라우터의 관리 주소를 기록하세요. 대체 관리 경로가 없는 상태에서 관리 IP, DHCP, 방화벽을 동시에 변경하지 마세요.
-
고정 관리 주소 설정
보조 라우터에서 「네트워크」→「인터페이스」→「LAN」→「편집」→「일반 설정」으로 이동한 뒤 고정 주소
192.168.10.2, 서브넷 마스크255.255.255.0을 설정하고 상위 IPv4 게이트웨이에192.168.10.1을 입력합니다. -
DHCP 서버는 하나만 유지
주소 할당은 메인 라우터에서 계속 담당하게 합니다. 보조 라우터에서 「네트워크」→「인터페이스」→「LAN」→「편집」→「DHCP 서버」→「일반 설정」으로 이동해 「이 인터페이스 무시」를 선택하세요. 두 장비가 서로 충돌하는 설정을 배포하는 일을 막을 수 있습니다.
-
기기 한 대의 게이트웨이 변경
테스트 기기의 IPv4 설정에서 기존 주소와 서브넷 마스크는 유지하고 게이트웨이만
192.168.10.2로 바꾸세요. 보조 라우터에서 IPv4 전달이 활성화되어 있고 해당 방화벽이 필요한 전달 방향을 허용하는지 확인합니다. -
DNS 경로 확인
보조 라우터에서 접속 가능한 DNS 서비스가 제공되는 것을 확인한 뒤에만 테스트 기기의 DNS를
192.168.10.2로 변경하세요. UDP/TCP 53 포트, 상위 DNS 조회 경로, 프록시가 시작되기 전에 노드 서버 도메인을 확인할 수 있는지 각각 점검합니다. -
범위 확대 및 검증
기기 한 대에서 안정성을 확인한 뒤 메인 라우터도 LuCI를 사용한다면 「네트워크」→「인터페이스」→「LAN」→「편집」→「DHCP 서버」→「고급 설정」의 DHCP 옵션에
3,192.168.10.2를 설정할 수 있습니다. DNS도 함께 배포해야 할 때는6,192.168.10.2를 추가하고, 이후 기기에서 DHCP 임대를 갱신하세요.
같은 네트워크 대역을 사용하는 단일 포트 보조 라우터에서는 비대칭 경로가 생길 수 있습니다. 기기는 보조 라우터를 거쳐 직접 연결 트래픽을 보내지만 메인 라우터는 기기로 바로 응답할 수 있습니다. 이로 인해 연결 추적, 통계, 방화벽 판정에 문제가 생길 수 있습니다. 보조 라우터가 전달하는 트래픽에 소스 NAT를 적용할지는 네트워크 구성에 따라 검증하세요. 소스 NAT를 사용하면 응답 경로를 더 쉽게 제어할 수 있지만 원래 기기 주소가 가려지므로 모든 네트워크에 적용할 정답은 아닙니다.
5. 하드웨어 사양: 이더넷 포트 속도가 아니라 목표 부하로 측정하세요
기가비트 이더넷 포트는 링크 협상 속도만 나타내며 암호화 프록시도 같은 속도를 낼 수 있다는 뜻은 아닙니다. CPU의 단일 코어 성능, 프로토콜과 전송 방식 조합, 메모리 압박, 발열, 노드 회선이 처리량을 제한할 수 있습니다. 소형 라우터에서는 무선 기능, 연결 추적, 방화벽을 위한 리소스도 남겨야 합니다. 보조 라우터라면 네트워크 카드 드라이버와 가상화 오버헤드도 확인하세요.
| 점검 항목 | 확인할 내용 | 판단 기준 |
|---|---|---|
| CPU와 발열 | top으로 코어별 사용률을 확인하고 10분간 부하를 유지합니다 | 처리량이 정체되고 특정 코어가 계속 최대 부하라면 연산 성능과 발열로 인한 클럭 저하를 먼저 확인합니다 |
| 메모리 여유 | free와 커널 로그를 확인하고 규칙 업데이트 시 다시 기록합니다 | 사용 가능한 메모리, 프로세스 종료, 메모리 부족으로 인한 종료 기록을 확인합니다 |
| 저장 공간 | df로 쓰기 가능한 파티션과 임시 디렉터리를 확인합니다 | 프로그램 업데이트, 규칙 파일, 로그 순환에 필요한 여유 공간을 확보합니다 |
| 동시 연결 | 기기 1대와 3대를 차례로 사용해 같은 작업을 반복합니다 | 지연 시간과 오류율을 비교하고 최고 다운로드 속도만 기록하지 마세요 |
같은 유선 기기, 같은 노드, 같은 다운로드 대상을 사용해 직접 연결 기준값, 기기 클라이언트 프록시, 보조 라우터 프록시의 세 가지 결과를 차례로 기록하세요. 각 조건에서 3회 반복 측정하고 처리량, 지연 시간, CPU, 메모리 사용량을 기록합니다. 노드 상태가 크게 변동한다면 결과 차이를 모두 보조 라우터 탓으로 돌릴 수 없습니다. 이 내용은 측정 방법이며 특정 기기의 실측 성능을 보장하지 않습니다.
결론: 병목을 찾은 뒤 장비 업그레이드를 결정하세요
보조 라우터의 단일 코어가 계속 최대 부하인데 기기 클라이언트는 안정적으로 더 빠르게 작동한다면 연산 성능을 먼저 높일 근거가 됩니다. 양쪽 모두 느려졌다면 다른 시간대나 노드로 비교 테스트를 먼저 진행하세요. 포트의 표기 속도가 낮다는 이유만으로 장비 전체를 교체할 필요는 없습니다.
6. 문제 해결 순서: 주소, 전달, 인바운드, 아웃바운드를 단계별로 확인하세요
“보조 라우터 관리 페이지가 열린다”는 것은 로컬 네트워크에서 해당 주소에 접속할 수 있다는 뜻일 뿐, 인터넷 전달이나 프록시 아웃바운드가 정상이라는 의미는 아닙니다. 먼저 보조 라우터의 기본 경로를 확인하고, 투명 프록시 인바운드가 실제로 트래픽을 받는지 살핀 뒤, 연결 로그에서 라우팅 규칙이 어떤 아웃바운드를 선택했는지 확인하세요. 디버그 로그에는 대상 도메인과 주소가 포함될 수 있으므로 문제 해결 후에는 일반 로그 수준으로 되돌리고 로그 순환을 설정하세요.
# 다음은 읽기 전용 점검 명령입니다. 일부 최소 구성 펌웨어에서는 해당 도구를 먼저 설치해야 합니다.
ip -4 addr show
ip -4 route show
ip -4 rule show
ip -4 route show table 100
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset
free
df -hip -4 route show table 100은 이 문서의 예시 번호를 실제로 사용하는 구성에서만 유효합니다. 관리 서비스가 다른 라우팅 테이블을 사용한다면 실제 번호를 조회하세요. ss로 포트와 프로세스를 확인할 수 있지만, 수신 중이라는 결과만으로 투명 프록시 규칙이 올바르다고 판단할 수는 없습니다. nft 출력에서는 기존 규칙 집합과 일치 횟수를 확인하세요. “문제 원인 제거”를 위해 방화벽 전체를 초기화하지 마세요.
게이트웨이를 보조 라우터로 바꾼 뒤 모든 웹사이트에 접속할 수 없다면?
먼저 테스트 기기의 게이트웨이를 192.168.10.1로 되돌리세요. 그런 다음 보조 라우터의 기본 경로가 메인 라우터를 가리키는지, net.ipv4.ip_forward 값이 1인지, 전달 방화벽이 트래픽을 허용하는지 확인합니다. 일반적인 트래픽 전달부터 복구한 뒤 가로채기 규칙을 다시 적용하세요.
웹은 열리지만 게임이나 음성 통화가 연결되지 않는다면?
앱이 UDP에 의존하는지 확인한 뒤 투명 인바운드, TPROXY 규칙, 정책 라우팅, 노드 아웃바운드가 모두 해당 트래픽을 지원하는지 점검하세요. TCP 리디렉션만 설정된 경우 DNS를 바꿔도 UDP 트래픽을 가로챌 수 없습니다.
분할 라우팅을 설정했는데 일부 도메인이 잘못된 경로로 연결되는 이유는?
먼저 예상한 DNS 확인기가 조회를 처리하는지 살펴보고 규칙 순서와 로그의 대상 정보를 확인하세요. 앱 자체 암호화 DNS는 로컬 53 포트를 거치지 않을 수 있습니다. 스니핑으로 모든 도메인을 알아낼 수 있다고 보장할 수도 없으므로 테스트할 앱에서 개별적으로 검증하세요.
재부팅 후 작동하지 않습니다. 노드에 문제가 생긴 걸까요?
코어 서비스가 실행 중인지, 투명 규칙이 로드됐는지, 정책 라우팅이 등록됐는지, 시스템 시간이 동기화됐는지 차례대로 확인하세요. 이 작업을 사용 중인 펌웨어의 서비스 관리 절차에 포함해야 합니다. 대화형 터미널에서 명령을 한 번 실행하는 데 그치지 마세요.
7. 운영과 복구: 게이트웨이 설정도 유지 관리 항목에 포함하세요
보조 라우터를 안정적으로 운영하려면 설정 파일뿐 아니라 시작 순서와 오류 처리도 중요합니다. 시간이 동기화되지 않거나 DNS가 준비되지 않았거나 규칙 다운로드에 실패하면 부팅 중 서비스가 비정상적으로 작동할 수 있습니다. 자동 업데이트 전에 새 설정을 검사한 뒤 현재 파일을 교체하세요. 프로세스가 살아 있다는 사실만으로 네트워크 경로가 정상이라고 판단해서는 안 됩니다.
- 복구 가능한 설정 저장: 네트워크, 방화벽, DNS, 코어 설정을 각각 백업하고 사용 중인 수신 포트, 마크, 라우팅 테이블 번호를 기록합니다.
- 전원 종료 후 재시작 테스트: 재부팅 후 주소 할당과 노드 도메인 조회, 직접 연결 및 프록시 경로를 확인하고 관리 페이지에 계속 접속할 수 있는지 확인합니다.
- 관리 범위 제한: 관리 페이지와 프록시 수신 포트는 필요한 로컬 네트워크에만 개방하고, 인증되지 않은 프록시 포트를 인터넷에 노출하지 마세요.
- 복구 절차 마련: 먼저 기기 설정이나 DHCP에서 배포하는 게이트웨이와 DNS를 원래대로 복원한 다음 트래픽 가로채기 규칙, 정책 라우팅, 서비스를 제거하세요. 코어만 중지하고 가로채기 규칙을 남겨 두면 트래픽이 수신 대기 중인 프로세스가 없는 포트로 전달될 수 있습니다.
프록시를 사용할 기기가 한두 대뿐이라면 기기 클라이언트가 보통 관리하기 쉽습니다. 로컬 네트워크 전체의 트래픽을 실제로 전환해야 한다면 기기 한 대로 시험한 뒤 DNS, UDP, IPv6를 확인하고 전체 네트워크로 확대하세요. 용어 설명은 용어 안내서에서 확인할 수 있습니다. 연결 범위와 라우팅 규칙에 따른 트래픽 분할의 차이는 사용 설명서를 참고하세요.