보조 라우터 구성: 트래픽 경로부터 확인하기
OpenWrt에서 mihomo를 실행하려면 커널 프로세스, 트래픽 가로채기, DNS를 각각 설정해야 합니다. 커널은 config.yaml을 읽고 rules에 따라 아웃바운드를 선택합니다. Linux 라우팅과 방화벽은 어떤 패킷을 커널로 보낼지 결정하고, DNS는 단말에 주소를 제공하며 도메인 정보가 트래픽 분기에 활용될 수 있도록 합니다. 프로세스를 실행하는 것만으로는 일부만 설정된 것이며, LAN에 투명 프록시가 적용된 것은 아닙니다.
이 글에서는 단일 포트, 동일 서브넷의 보조 라우터 구성을 예로 듭니다. 아래 주소는 네트워크 구조를 설명하기 위한 예시이므로 실제 배포 시에는 사용 중인 네트워크 주소로 바꾸고 IP 주소가 충돌하지 않는지 확인하세요.
| 장치 | 예시 주소 | 역할 |
|---|---|---|
| 주 라우터 | 192.168.10.1/24 | ISP 네트워크에 연결하고 DHCP 서비스 유지 |
| OpenWrt 보조 라우터 | 192.168.10.2/24 | mihomo 실행, 트래픽 전달 및 DNS 처리 |
| 테스트 PC | 192.168.10.100/24 | 먼저 단독으로 검증하고 전체 네트워크 설정은 바로 변경하지 않음 |
테스트 PC의 IPv4 기본 게이트웨이는 192.168.10.2를 가리키고, 보조 라우터의 기본 경로는 주 라우터 192.168.10.1을 가리켜야 합니다. 두 장치가 서로를 기본 게이트웨이로 지정해 순환 경로가 생기지 않도록 하세요. 보조 라우터에서는 IPv4 포워딩을 활성화하고 필요한 인터페이스 또는 방화벽 영역 간 포워딩을 허용해야 합니다. 이는 보조 라우터 자체로 들어오는 입력 포트를 허용하는 것과는 별개의 설정입니다.
커널 아키텍처와 설정 디렉터리
CPU, 시스템, 실행 환경 확인하기
먼저 SSH로 시스템 정보를 확인한 다음 해당 Linux 커널 빌드를 선택하세요. x86_64는 보통 amd64, aarch64는 보통 arm64에 해당합니다. 32비트 ARM은 명령어 세트와 부동소수점 ABI도 확인해야 합니다. 라우터 제품명만으로 판단하지 말고, OpenWrt 패키지의 아키텍처 이름을 커널 배포 파일명과 동일시하지 마세요.
uname -m
ubus call system board
cat /etc/openwrt_release
df -h /overlay /tmp
free -mamd64 빌드를 선택할 때는 릴리스 노트에 명시된 CPU 명령어 세트 요구 사항도 확인하세요. 실행 중 Illegal instruction 오류가 발생하면 장치 성능보다 높은 빌드를 선택했는지 확인합니다. Exec format error가 발생하면 먼저 아키텍처와 파일 형식을 점검하세요. Permission denied라면 실행 권한과 마운트 옵션을 확인해야 하며, 구독 설정 문제로 단정해서는 안 됩니다.
영구 파일과 임시 로그는 분리해 저장하기
독립적으로 배포할 때는 커널을 /usr/bin/mihomo, 설정 디렉터리를 /etc/mihomo, 기본 설정 파일을 /etc/mihomo/config.yaml에 두는 방식으로 정할 수 있습니다. 이 경로는 이 글에서 사용하는 예시이며 모든 OpenWrt 관리 플러그인의 기본 경로는 아닙니다. 이미 관리 플러그인을 사용 중이라면 동일한 관리 도구에서 프로세스와 방화벽을 관리하고, 별도의 인스턴스를 추가로 실행하지 마세요.
/etc/mihomo/config.yaml: 기본 설정 파일을 저장합니다. 구독 URL이나 인증 정보가 포함된 경우 읽기 권한을 제한하세요./etc/mihomo/providers/: 설정에서 참조하는 provider 파일을 저장할 수 있습니다. 실제 상대 경로는 해당 필드의 설정에 따라 달라집니다./tmp/: 임시 진단 파일을 두기에 적합합니다. 보통 재부팅 후 파일이 남지 않으므로 유일한 설정 파일 사본을 저장하지 마세요.- 규칙 세트와 지리 데이터는 실제 설정에 필요한 항목만 준비하세요. 먼저 플래시 저장 공간과 메모리를 확인하고 모든 데이터 소스를 기본적으로 활성화하지 마세요.
mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml아래 명령은 커널과 설정 파일이 해당 경로에 이미 저장되어 있다고 가정합니다. -t는 설정을 검사하는 옵션이며, 노드 연결이나 방화벽의 트래픽 가로채기가 정상인지까지 확인해 주지는 않습니다. 검사에 통과하면 포그라운드에서 실행해 시작 로그를 확인하세요. 백그라운드 상시 실행이 필요하면 OpenWrt의 procd 서비스로 프로세스를 관리하고, SSH 세션의 임시 백그라운드 작업에 의존하지 마세요.
/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml먼저 mixed-port를 확인한 다음 투명 프록시 연결하기
먼저 테스트 PC 한 대에서 명시적 프록시를 사용해 구독, 아웃바운드, 규칙 문제를 분리해 확인하는 것이 좋습니다. 다음은 리스닝 여부를 확인하는 기본 설정입니다. 프록시 노드는 포함하지 않고 모든 규칙을 직접 연결로 설정했으므로 프로세스, 포트, 요청 경로만 확인할 수 있습니다. 프록시 아웃바운드를 확인하려면 유효한 설정을 사용하고 proxies, proxy-providers, proxy-groups, rules의 이름 참조가 올바른지 확인하세요.
mixed-port: 7890
allow-lan: true
bind-address: "192.168.10.2"
mode: rule
log-level: info
ipv6: false
rules:
- MATCH,DIRECTmixed-port: 7890은 HTTP와 SOCKS 프록시 연결 포트를 제공합니다. allow-lan: true는 다른 장치의 연결을 허용하고, bind-address는 리스닝 주소를 제한합니다. 이 주소는 보조 라우터에 실제로 설정되어 있어야 합니다. OpenWrt 방화벽에서는 신뢰할 수 있는 LAN에만 TCP 7890을 허용하고 WAN에는 프록시 포트를 개방하지 마세요.
테스트 PC에서 아래 요청을 실행할 수 있습니다. 기본 설정에서는 직접 연결에 성공해야 합니다. 유효한 노드와 규칙으로 바꾼 뒤에는 mihomo 로그를 확인해 실제 아웃바운드를 점검하세요. HTTP 요청 한 번의 성공만으로 UDP, DNS, 전체 네트워크의 투명 프록시가 정상이라고 판단할 수는 없습니다.
curl -I --proxy http://192.168.10.2:7890 https://example.com/여기서 실패하면 TProxy를 조정하기에 앞서 리스닝 주소, 방화벽 입력 규칙, 커널 로그부터 확인하세요. PC의 명시적 프록시는 정상인데 게이트웨이를 변경한 뒤 실패한다면 포워딩, 방화벽 가로채기, 정책 라우팅, DNS 쪽으로 점검 범위를 좁힐 수 있습니다.
Redir, TProxy, TUN의 차이
| 연결 방식 | mihomo 설정 필드 | 주요 적용 범위 | 시스템 측 추가 설정 |
|---|---|---|---|
| Redir | redir-port: 7892 | Linux에서 TCP 투명 리디렉션 | 방화벽 REDIRECT 규칙과 트래픽 제외 설정 |
| TProxy | tproxy-port: 7893 | Linux에서 TCP·UDP 투명 프록시 | TPROXY 규칙, 패킷 마킹, 정책 라우팅 |
| TUN | tun.enable: true | 가상 네트워크 인터페이스로 IP 트래픽 수신 | TUN 지원, 라우팅, 방화벽 연동 |
Redir: 포트 리스닝만으로 트래픽이 가로채지는 것은 아닙니다
redir-port는 투명 프록시의 진입점이지, 앱에 입력하는 HTTP 프록시 포트가 아닙니다. Linux의 Redir는 주로 TCP에 사용되므로 UDP까지 프록시된다고 볼 수 없습니다. TCP 리디렉션만 설정하면 QUIC, 게임, 음성 통화의 UDP 트래픽은 남아 있는 방화벽 규칙에 따라 직접 연결되거나 실패할 수 있습니다.
TProxy: 패킷을 로컬 장치로 보내는 정책 라우팅 필요
TProxy는 TCP와 UDP를 처리하면서 원래 목적지 정보를 보존할 수 있습니다. 배포할 때는 대상 트래픽에 마크를 지정한 뒤 ip rule과 해당 라우팅 테이블을 사용해 로컬 투명 리스너로 전달해야 합니다. tproxy-port: 7893만 설정하고 시스템 규칙을 추가하지 않으면 단말 트래픽은 자동으로 mihomo에 전달되지 않습니다.
방화벽에서는 LAN, 브로드캐스트, 멀티캐스트, 필요한 로컬 서비스, 커널 자체의 아웃바운드 연결을 제외해 프록시 루프를 방지해야 합니다. 마크 값과 라우팅 테이블 번호는 시스템에 이미 설정된 VPN, 트래픽 분기, 멀티 WAN 규칙과 겹치지 않아야 합니다. 다른 장치의 숫자를 그대로 가져온다고 반드시 동작하는 것은 아닙니다.
TUN: 별도의 트래픽 가로채기 방식이며 단순히 추가로 켜는 옵션이 아닙니다
TUN을 사용하려면 시스템에서 TUN 장치와 필요한 권한을 제공해야 합니다. tun.auto-route는 라우트를 자동으로 설정하며, 지원되는 Linux 환경에서는 tun.auto-redirect도 방화벽을 통한 트래픽 가로채기와 관련됩니다. 관리 플러그인이 이미 설정한 투명 프록시 규칙과 무작정 함께 사용하지 마세요. 보조 라우터에서는 먼저 주된 트래픽 가로채기 방식을 하나 선택한 다음 해당 방식에 맞춰 제외 규칙과 롤백 절차를 설정하세요.
DNS 포워딩: dnsmasq와 mihomo가 각각 다른 포트를 사용하도록 설정하기
OpenWrt에서는 보통 dnsmasq가 LAN에 53번 포트로 DNS 서비스를 제공합니다. mihomo도 같은 주소의 53번 포트를 사용하면 충돌이 발생합니다. 확인하기 쉬운 구성으로는 단말이 보조 라우터의 53번 포트에 질의하고, dnsmasq가 요청을 로컬 mihomo의 1053번 포트로 전달하도록 설정할 수 있습니다.
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: redir-host
nameserver:
- 223.5.5.5
- 119.29.29.29이 설정은 로컬 포워딩 구조를 설명하기 위한 것이며, 표시된 업스트림은 일반 DNS이므로 모든 네트워크에서 적합하다고 보장할 수 없습니다. dnsmasq의 업스트림을 127.0.0.1#1053으로 지정할 수 있습니다. 요청이 의도한 경로를 우회하지 않도록 다른 업스트림을 계속 참조하는지도 확인하세요. mihomo의 업스트림을 다시 dnsmasq의 53번 포트로 지정하면 DNS 조회 루프가 발생합니다.
redir-host와 fake-ip는 트래픽 가로채기 방식에 맞춰 선택하기
redir-host는 단말에 실제 주소를 반환합니다. fake-ip는 매핑된 주소를 반환하고, 커널이 연결을 가로챌 때 도메인 연결 정보를 복원합니다. fake-ip를 사용하면 매핑 주소를 받은 단말의 후속 연결이 mihomo로 돌아와야 합니다. DNS만 전환하고 투명 프록시 연결을 마치지 않은 경우 도메인은 조회되지만 모든 연결이 실패할 수 있습니다.
- 먼저 단말 하나로 DNS 경로를 확인하고 로그에 해당 질의가 기록되는지 확인한 뒤 적용 범위를 넓히세요.
- 도메인을 사용하는 암호화 DNS 업스트림을 쓴다면 설정에 따라 업스트림 도메인의 부트스트랩 조회도 처리해야 합니다.
- 단말의 프라이빗 DNS나 브라우저의 보안 DNS가 DHCP로 전달된 DNS 서버를 우회할 수 있으므로 각각 확인하세요.
- DNS나 fake-ip 모드를 변경한 뒤에는 테스트 단말의 DNS 캐시를 지우고 연결을 다시 설정하세요. 이전 결과가 점검을 방해하지 않도록 할 수 있습니다.
게이트웨이 설정, 응답 경로, IPv6
먼저 단말 한 대에서 변경한 다음 DHCP를 조정하기
LuCI의 「네트워크」→「인터페이스」에서 보조 라우터의 LAN 주소가 192.168.10.2이고 IPv4 게이트웨이가 192.168.10.1인지 확인하세요. 화면의 항목은 버전이나 관리 플러그인에 따라 달라질 수 있으므로 최종적으로는 인터페이스 주소와 라우팅 테이블을 기준으로 판단해야 합니다. 먼저 테스트 PC의 게이트웨이와 DNS를 보조 라우터 주소로 수동 설정해 확인하고, 검증이 끝난 뒤 전체 네트워크에 적용하세요.
주 라우터에서 DHCP를 계속 제공한다면 옵션 3에 192.168.10.2, 옵션 6에도 192.168.10.2를 지정할 수 있습니다. 각각 IPv4 게이트웨이와 DNS 서버를 의미합니다. 같은 브로드캐스트 도메인에서 계획 없이 DHCP 서버 두 대를 동시에 실행하지 마세요. 설정을 바꾼 뒤에는 단말의 임대 갱신도 필요하며, 기존 임대 정보가 즉시 모두 업데이트되지는 않습니다.
같은 서브넷의 응답 트래픽이 보조 라우터를 경유한다고 단정할 수 없습니다
단일 포트 보조 라우터 구성에서는 보조 라우터에서 주 라우터로 전달된 직접 연결의 응답 패킷이 주 라우터에서 단말로 곧바로 전달되어 비대칭 경로가 생길 수 있습니다. 일부 구성에서는 보조 라우터에서 주 라우터로 나가는 방향에 소스 NAT를 적용해 응답이 보조 라우터로 돌아오도록 합니다. 다만 이 경우 단말의 원래 소스 주소가 숨겨집니다. SNAT나 masquerade가 필요한지는 네트워크 구조, 상태 추적, 트래픽 가로채기 방식에 따라 달라지므로 무조건 켜야 하는 것은 아닙니다.
같은 서브넷의 트래픽을 전달할 때는 ICMP Redirect도 확인하세요. 단말이 더 직접적인 경로 안내를 받아 이후 경로를 바꿀 수 있습니다. 처음에는 보조 라우터를 경유하지만 이후 우회한다면 단말의 라우팅 캐시와 보조 라우터 관련 커널 매개변수도 함께 점검하세요.
IPv4 게이트웨이 설정만으로 IPv6 트래픽은 가로채지지 않습니다
주 라우터가 RA로 전달한 IPv6 기본 경로가 여전히 유효할 수 있습니다. 설정에 ipv6: false를 지정해도 LAN 전체의 IPv6가 꺼지는 것은 아닙니다. IPv6 프록시가 필요하다면 IPv6 라우팅, 방화벽, DNS를 별도로 설계하세요. 아직 배포하지 않았다면 테스트 단말에서 IPv6 사용 범위를 제한하고 IPv4와 IPv6를 각각 확인해 우회 트래픽을 규칙 오류로 오판하지 않도록 하세요.
검증 순서와 롤백 점검
문제 해결은 로컬 장치, 명시적 프록시, 단말 한 대의 투명 프록시, 전체 네트워크 적용 순서로 진행하세요. 한 번에 한 계층만 변경하고 변경 전 게이트웨이, DNS, 방화벽 상태를 기록합니다. 관리 화면이 열린다는 것은 보조 라우터까지 로컬 연결이 가능하다는 뜻일 뿐, 인터넷 트래픽 전달이 정상이라는 의미는 아닙니다.
- 프로세스와 설정을 확인합니다.
mihomo -t를 실행하고 포그라운드에서 시작 오류를 확인하세요. 7890, 7892, 7893, 1053 포트를 점유한 두 번째 인스턴스가 없는지도 확인합니다. - 보조 라우터의 인터넷 연결을 확인합니다.
ip -4 route를 실행해 기본 다음 홉을 확인하세요. HTTPS 요청이 시스템 시간 오류로 실패하지 않도록 시간과 DNS가 정상인지도 점검합니다. - 명시적 프록시를 확인합니다. 앞에서 안내한
curl --proxy요청을 실행하고 페이지가 열리는지만 보지 말고 로그에서 규칙과 실제 아웃바운드를 확인하세요. - 투명 프록시 연결을 확인합니다. 테스트 단말에서 명시적 프록시를 끄고 보조 라우터를 게이트웨이로 설정하세요.
ip rule show,ip route show table all, 방화벽 규칙의 카운터를 확인합니다. - DNS와 프로토콜 범위를 확인합니다.
nslookup example.com 192.168.10.2를 실행하세요. TCP 연결이 성공한 뒤 필요한 UDP 앱을 테스트하고, 마지막으로 IPv6를 별도로 확인합니다.
상시 실행 단계에 들어가면 procd로 자동 시작, 비정상 종료, 로그를 관리하고 네트워크와 필요한 파일이 준비된 뒤 실행되는지 확인하세요. 규칙 업데이트, provider 가져오기, 구독 다운로드도 추가 네트워크 요청을 발생시킬 수 있으므로 이러한 요청이 잘못 가로채지지 않는지 확인해야 합니다. 플래시 저장 공간이 제한된 장치에서는 디버그 로그를 장기간 저장하지 마세요.
보조 라우터 배포의 검수 기준은 특정 스위치가 ‘실행 중’으로 표시되는지가 아니라 게이트웨이 설정, DNS 포워딩, 투명 프록시 진입점, 아웃바운드 규칙이 단계별로 맞물려 동작하는지입니다. 설정 필드를 확인하려면 설정 참조를 살펴보세요. 같은 구독을 PC에서 먼저 검증하려면 클라이언트부터 설정하고 구성이 유효한지 확인한 다음 OpenWrt로 옮기면 됩니다.