Linux 라우터 및 보조 라우터 구축 개요: 커널 직접 실행과 트래픽 가로채기 범위

먼저 ‘커널 직접 실행’이 가로채는 범위를 구분하기

여기서 ‘커널’은 사용자 공간에서 실행되는 V2Ray 또는 Xray 프록시 코어를 뜻하며, 프록시 기능을 Linux 커널에 컴파일한다는 의미가 아닙니다. 프록시 코어는 인바운드 포트로 전달된 연결을 받아 라우팅 규칙에 따라 직접 연결, 차단 또는 원격 아웃바운드를 선택합니다. 네트워크 인터페이스, 주소, 라우팅 테이블, 연결 추적, 포워딩, 방화벽은 여전히 Linux가 담당합니다.

따라서 프로그램에 ‘실행 중’이라고 표시되어도 프로세스가 시작되었다는 뜻일 뿐, 로컬 네트워크 트래픽이 반드시 해당 프로세스를 통과한다는 의미는 아닙니다. 게이트웨이가 트래픽을 인계받으려면 패킷이 먼저 Linux 호스트에 도착한 뒤 nftables 또는 iptables가 대상 트래픽을 투명 프록시 인바운드로 전달해야 합니다. 응답 트래픽도 예측 가능한 경로로 원래 기기까지 돌아가야 하며, 그렇지 않으면 연결 직후 끊기거나 일부 웹사이트만 열리고 다른 앱은 시간 초과되는 문제가 발생합니다.

게이트웨이, DNS, 포워딩, 프록시 코어의 역할

기본 게이트웨이는 ‘패킷의 다음 홉이 어디인가’를 결정합니다. DNS는 ‘도메인이 어떤 주소로 해석되는가’를 반환합니다. Linux 포워딩은 한 인터페이스로 들어온 패킷이 다른 인터페이스로 나갈 수 있게 하며, 프록시 코어는 실제로 인바운드에 전달된 연결만 처리합니다. 네 요소는 함께 작동하지만 어느 하나가 정상이라고 해서 나머지 세 요소까지 구축되었다고 볼 수는 없습니다.

예를 들어 단말이 Linux의 DNS 서비스에서 올바른 주소를 받아도 패킷은 기존 라우터로 보낼 수 있습니다. 반대로 기본 게이트웨이를 Linux로 변경했더라도 시스템에서 IPv4 포워딩을 활성화하지 않았다면 로컬 네트워크 외부 주소에 연결할 수 없습니다. 포워딩과 투명 인바운드가 정상이어도 방화벽에서 게이트웨이 자체, 로컬 네트워크 대역 또는 원격 서버 주소를 제외하지 않으면 루프가 발생할 수 있습니다.

메인 라우터와 보조 라우터의 트래픽 경로 차이

메인 라우터 모드에서는 Linux가 일반적으로 로컬 네트워크 인터페이스와 상위 네트워크 인터페이스를 모두 보유하며, 단말은 DHCP를 통해 Linux를 기본 게이트웨이로 자동 설정합니다. 패킷은 로컬 네트워크 인터페이스로 들어와 라우팅 판단, 방화벽, 프록시 규칙을 거친 뒤 상위 네트워크 인터페이스로 나갑니다. 경로가 일원화되어 분기 규칙을 관리하기 쉽지만 DHCP, NAT 또는 포워딩 중 한 곳만 잘못되어도 전체 네트워크가 외부 연결을 잃을 수 있습니다.

보조 라우터 모드에서는 기존 라우터가 인터넷 연결과 주소 할당을 계속 담당하고 Linux 호스트는 같은 로컬 네트워크에 위치합니다. 기본 게이트웨이를 보조 라우터로 명시한 단말만 보조 라우터를 통과합니다. 단말의 게이트웨이가 여전히 기존 라우터이고 DNS만 보조 라우터로 변경하면, 보조 라우터는 일반적으로 DNS 쿼리만 볼 수 있고 이후 연결은 볼 수 없습니다. 따라서 투명 프록시 규칙도 적용되지 않습니다.

응답 경로도 확인해야 합니다. 보조 라우터가 패킷을 기존 라우터로 전달한 뒤에는 기존 라우터가 응답을 단말로 돌려보내는 방법을 알아야 합니다. 일반적인 방법은 보조 라우터의 출구에서 소스 주소 변환을 수행하거나 기존 라우터에 테스트 네트워크 대역으로 향하는 정적 라우트를 추가하는 것입니다. 전자는 구축이 간단하지만 기존 라우터에는 보조 라우터 주소로 보입니다. 후자는 원본 주소를 유지하는 대신 네트워크 장비에 명확한 라우팅 설정 기능이 필요합니다.

• 메인 라우터 경로: 단말 → Linux 기본 게이트웨이 → 투명 프록시 또는 직접 연결 규칙 → 상위 네트워크
• 보조 라우터 경로: 테스트 단말 → Linux 보조 라우터 → 기존 라우터 → 상위 네트워크
• DNS만 변경: 단말 → Linux에서 도메인 조회, 실제 연결은 기존 라우터로 직접 전송될 수 있음
• 명시적 프록시 경로: 단말 애플리케이션 → Linux HTTP/SOCKS 인바운드 → 프록시 코어 아웃바운드, 투명 규칙에 의존하지 않음

롤백 가능한 순서로 구축 완료하기

구축할 때는 ‘노드를 사용할 수 있는가’와 ‘게이트웨이가 트래픽을 인계받는가’를 두 단계로 나누어 테스트해야 합니다. 먼저 명시적 프록시로 코어 설정과 원격 연결을 검증한 다음 Linux 포워딩과 투명 규칙을 활성화하세요. 문제가 발생해도 프록시 아웃바운드인지 로컬 네트워크 경로인지 빠르게 판단할 수 있습니다.

1. 기존 네트워크 기록

   테스트 단말의 기존 IP, 서브넷 마스크, 기본 게이트웨이, DNS를 저장합니다. 보조 라우터도 로컬 네트워크 주소를 고정해 DHCP 임대 변경으로 관리 경로를 잃지 않도록 합니다.

2. 코어 아웃바운드 검증

   먼저 V2Ray 또는 Xray가 테스트 전용 HTTP/SOCKS 포트(예: 10808)를 수신하도록 설정하고, 단일 애플리케이션에 해당 주소를 직접 입력합니다. 이 단계에서는 투명 포워딩을 활성화하지 않습니다.

3. 코어 유형 확인

   Windows 테스트 단말에서 같은 노드 매개변수를 교차 검증하려면 v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」을 열어 선택한 코어가 프로토콜 설정과 일치하는지 확인할 수 있습니다.

4. 시스템 포워딩 활성화

   net.ipv4.ip_forward가 1인지 확인한 다음 FORWARD 체인이 테스트 네트워크 대역을 통과시키는지 확인합니다. 먼저 일반 라우팅을 사용할 수 있게 유지하고 투명 규칙 추가는 서두르지 마세요.

5. 투명 인바운드 연결

   TProxy에 패킷 표시, 정책 라우팅, 로컬 라우팅 테이블을 설정해 선택한 TCP/UDP 트래픽을 12345로 전달하고, 로컬 네트워크, 멀티캐스트, 브로드캐스트, 게이트웨이 자체, 원격 서버 주소는 제외합니다.

6. 범위를 단계적으로 확대

   먼저 고정 IP 하나를 테스트한 뒤 기기 그룹 단위로 확대합니다. 한 번에 게이트웨이, DNS 또는 규칙 중 하나만 변경하고, 투명 규칙을 비활성화한 뒤 일반 포워딩으로 복구할 수 있는 관리 경로를 유지하세요.

아래 명령은 상태를 확인하기 위한 것이며 방화벽 규칙을 대신 생성하지 않습니다. 출력에서 포워딩 값, 정책 규칙, 라우팅 테이블, 수신 포트가 실제 설정과 일치하는지 확인해야 합니다. 시스템이 nftables를 사용한다면 호환 계층의 표시만 보지 말고 실제 규칙 집합을 직접 확인하세요.

sysctl net.ipv4.ip_forward
ip rule show
ip route show table 100
nft list ruleset
ss -lntup | grep -E '(:53|:10808|:12345)'

TProxy, 리디렉션, TUN 선택 방법

투명 프록시를 구현하는 방법은 하나뿐이 아닙니다. TCP 리디렉션 규칙은 이해하기 쉽지만 원래 목적지와 UDP 처리 능력이 구현 방식에 따라 제한됩니다. TProxy는 목적지 정보를 유지하면서 TCP와 UDP를 수신할 수 있어 도메인, IP, 전송 계층을 함께 사용하는 게이트웨이 분기에 적합합니다. 다만 방화벽 표시, 정책 라우팅, 프록시 코어의 투명 인바운드 설정이 필요해 문제 해결 단계가 더 많습니다.

TUN은 프록시 코어가 가상 네트워크 인터페이스를 만들고 라우팅 계층에서 트래픽을 수신하는 방식입니다. 일부 방화벽 리디렉션 로직을 줄일 수 있지만 라우팅, DNS, 인터페이스 권한, 우회 규칙을 올바르게 설정해야 합니다. 기본 라우트가 실수로 TUN을 다시 가리키면 원격 서버 연결도 프록시 자체로 되돌아가 루프가 발생할 수 있습니다.

초기 구축 단계에서는 TProxy와 TUN을 동시에 적용하지 않는 것이 좋습니다. 두 인계 체인이 함께 존재하면 하나의 연결이 중복 처리될 수 있고, 로그에는 계속 재연결된다는 사실만 나타나 트래픽이 어느 단계에서 루프를 일으키는지 파악하기 어렵습니다. 먼저 한 가지 방식으로 TCP, UDP, DNS를 정상화한 뒤 다른 방식으로 전환할 필요가 있는지 판단하세요.

DNS와 라우팅 분기를 따로 검증하기

도메인 기반 분기에는 신뢰할 수 있는 도메인 정보가 필요합니다. 프록시 코어는 인바운드 프로토콜, DNS 결과 또는 트래픽 탐지를 통해 도메인을 얻을 수 있지만 이 정보원이 항상 동일한 것은 아닙니다. 단말이 이미 도메인을 IP로 해석한 뒤 투명 트래픽으로 게이트웨이에 들어오면 코어에는 대상 IP만 보일 수 있으므로 도메인 규칙만 설정하면 적용되지 않을 수 있습니다.

DNS의 자기 순환도 피해야 합니다. 예를 들어 Linux의 로컬 DNS가 쿼리를 프록시 코어로 전달하고, 코어의 업스트림 도메인을 확인하려면 다시 같은 로컬 DNS를 호출해야 한다면 쿼리가 원래 인바운드로 반복해서 돌아옵니다. 로컬 네트워크 수신 주소, 코어 내부 조회, 업스트림 해석 경로를 명확히 구분하고 로그에서 하나의 쿼리에 설명 가능한 요청과 응답만 발생하는지 확인하는 것이 안전합니다.

• 테스트 단말에서 직접 연결이 예상되는 도메인을 조회하고 반환 주소와 조회 시간을 기록합니다.
• 프록시 처리가 예상되는 도메인을 조회하고 요청이 지정한 DNS 인바운드에 도착하는지 확인합니다.
• 대상 IP로 연결을 시작해 IP 규칙과 도메인 규칙이 서로 다른 결과를 만드는지 확인합니다.
• TCP와 UDP를 각각 테스트해 브라우저에서 웹페이지가 열린다는 사실만으로 모든 프로토콜이 정상이라고 판단하지 않습니다.
• IPv4와 IPv6 경로를 확인합니다. IPv4 인계만 구축했다면 IPv6도 같은 규칙을 사용한다고 가정해서는 안 됩니다.

리소스 사용량, 검수 지표, 롤백 준비

게이트웨이 부하는 유휴 상태의 메모리만으로 판단할 수 없습니다. 암호화 연결 수, UDP 세션, 로그 수준, DNS 캐시, 규칙 규모가 모두 리소스 사용량에 영향을 줍니다. 소프트 인터럽트, 코어별 사용률, 네트워크 처리량도 관찰해야 합니다. 저전력 기기는 전체 CPU 사용률이 높지 않아도 특정 코어 하나가 이미 병목에 도달할 수 있습니다.

기준선 측정을 위한 한 가지 테스트 환경은 N5105 쿼드코어, 메모리 4GB, Linux 6.1, 기가비트 유선 인터페이스이며, 단일 단말이 500Mbps를 지속 전송하면서 약 800개의 연결을 유지합니다. 투명 프록시 실행 후 프록시 코어의 상주 메모리는 약 118MB, 전체 CPU 사용률은 18%~27% 사이였습니다. 이 결과는 기록 방법을 설명하기 위한 예시일 뿐이며 프로토콜, 암호화 방식, 규칙 수, 하드웨어에 따라 수치는 달라집니다.

검수 시 최소한 직접 연결 기준선, 명시적 프록시, 투명 인계 세 가지 결과를 기록하고 최초 DNS 조회 시간, 지속 처리량, 연결 설정, UDP, 규칙 적용을 각각 테스트해야 합니다. 투명 인계가 명시적 프록시보다明显하게 느리다면 프로토콜 이름을 바꾸기보다 MTU, 중복 인계, DNS 대기, 코어별 병목을 먼저 확인하세요.

1. 활성화 전 라우팅 테이블, 방화벽 규칙, DNS 설정, 시스템 포워딩 값을 백업합니다.
2. 투명 규칙과 정책 라우팅을 동시에 철회하는 명령 또는 서비스 작업을 준비합니다.
3. 기존 메인 라우터의 DHCP 설정을 유지하고 보조 라우터 시험 운영 중에는 즉시 삭제하지 않습니다.
4. 로그 순환을 설정해 디버그 로그가 장기간 디스크를 가득 채우지 않도록 합니다.
5. Linux 호스트를 재시작한 뒤 다시 검수해 네트워크 인터페이스가 준비되기 전에 규칙이 먼저 로드되지 않는지 확인합니다.

구축 전 최종 판단

소수의 애플리케이션만 프록시를 사용하면 명시적 프록시가 관찰하기 쉽고 전체 로컬 네트워크 경로를 변경할 필요도 없습니다. TV, 터미널 도구처럼 기기별 프록시 설정이 어려운 장치를 인계하려면 게이트웨이 모드의 가치가 분명하지만 라우팅, DNS, 방화벽, 프록시 코어를 함께 관리해야 합니다.

최초 구축은 보조 라우터와 테스트 단말 한 대로 시작하는 것이 좋습니다. 먼저 10808 명시적 프록시를 검증하고 시스템 포워딩을 활성화한 다음 투명 인바운드를 12345에 연결하세요. 규칙 적용, DNS 경로, TCP, UDP, IPv4, 롤백 절차를 확인한 뒤에야 DHCP를 이전하거나 Linux를 메인 라우터로 전환하는 것을 고려해야 합니다.

• 단말, Linux, 기존 라우터, 상위 네트워크 사이의 송신 및 응답 경로를 명확히 그릴 수 있습니다.
• 포트 53, 10808, 12345를 각각 어떤 프로세스가 수신하는지 설명할 수 있습니다.
• 프록시 코어를 중지하기 전에 트래픽 전달 규칙을 먼저 철회할 수 있습니다.
• 로그, 포트, 라우팅 테이블, 규칙 카운터를 교차 확인해 장애 위치를 판단할 수 있습니다.
• 프록시 경로에 의존하지 않고 Linux 관리 화면에 접속할 수 있습니다.