OpenWrt 보조 라우터에서 mihomo 실행하기: LAN 투명 프록시 구성과 주의사항

보조 라우터의 역할부터 정하기

보조 라우터는 특별한 프록시 프로토콜이 아니라 네트워크 구성 방식입니다. 보통 기존 메인 라우터에 OpenWrt 기기를 연결하고, 선택한 단말의 기본 게이트웨이로 지정합니다. 메인 라우터는 인터넷 연결, 무선 접속, 외부망 연결을 계속 담당하고 OpenWrt는 자신을 거치는 트래픽을 규칙에 따라 처리합니다.

mihomo는 Clash Meta 프로젝트에서 발전한 프록시 커널로, 설정을 읽고 규칙에 따라 연결을 처리합니다. 그 자체로 완전한 라우터 관리 인터페이스는 아닙니다. 기기에 커널을 복사하는 것만으로 배포가 끝나는 것은 아니며, 투명 프록시를 사용하려면 라우팅, DNS, 방화벽 규칙도 함께 설정해야 합니다.

트래픽 처리 방식 선택하기

• 명시적 프록시: 단말에 HTTP 또는 SOCKS 프록시 주소를 입력합니다. 구독과 노드의 작동 여부를 확인하기 좋지만, 프록시 설정을 따르는 앱만 프록시를 사용합니다.
• 투명 프록시: OpenWrt가 단말의 트래픽을 가로채거나 라우팅합니다. TProxy를 사용하거나 mihomo의 TUN 가상 네트워크 인터페이스와 연동할 수 있습니다. 두 방식은 필요한 커널 모듈과 라우팅 설정이 다릅니다.
• 통합 관리 플러그인: 플러그인이 커널, 설정, 방화벽을 관리합니다. LuCI 그래픽 인터페이스가 필요한 사용자에게 적합하지만, 먼저 사용 중인 OpenWrt 버전을 지원하는지 확인하세요.

투명 프록시를 관리할 방법은 하나만 선택하세요. 두 플러그인이 동시에 DNS 가로채기, 정책 라우팅, 방화벽 규칙을 수정하게 두지 말고, 플러그인이 자동 생성한 설정을 임시 실행 파일에서 직접 수정하지도 마세요.

주소, 기본 게이트웨이, DHCP 계획하기

단일 포트·단일 서브넷 구성의 예입니다. 메인 라우터는 192.168.10.1, OpenWrt는 192.168.10.2, 테스트용 Mac은 192.168.10.50이며 서브넷 마스크는 모두 255.255.255.0입니다. 예시 주소이므로 실제 설정 전에는 집에서 사용하는 주소 대역으로 바꾸고, 해당 주소가 이미 사용 중인지 확인하세요.

먼저 OpenWrt의 상위 연결 설정하기

1. 메인 라우터의 LAN 포트와 OpenWrt의 LAN 인터페이스를 랜 케이블로 연결합니다. 실제 포트 역할은 현재 네트워크 설정을 기준으로 확인하고, 기기 외관에 표시된 라벨만 믿지 마세요.
2. LuCI에서 「네트워크」→「인터페이스」→「LAN」→「편집」을 열고 고정 IPv4 주소와 서브넷 마스크, 메인 라우터를 가리키는 IPv4 게이트웨이를 설정합니다.
3. OpenWrt 자체에 사용할 수 있는 상위 DNS를 설정하세요. 프록시를 시작하기 전에도 커널을 내려받고 프록시 서버 도메인을 조회하며 구독을 갱신할 수 있어야 합니다.
4. 메인 라우터에서 DHCP를 계속 제공한다면 OpenWrt의 해당 LAN에서 「DHCP 서버」→「일반 설정」을 열고 「이 인터페이스 무시」를 선택하세요. 이 설정은 해당 인터페이스의 DHCP 주소 할당만 중지하며 DNS 서비스까지 중지하는 것은 아닙니다.

DHCP는 주소, 게이트웨이, DNS를 자동으로 할당하는 서비스입니다. 같은 브로드캐스트 도메인에서 서로 충돌하는 DHCP 서버를 임의로 두 개 실행하지 마세요. 그러면 단말이 어떤 때는 메인 라우터를, 다른 때는 보조 라우터를 게이트웨이로 받아 연결이 불안정해질 수 있습니다.

테스트용 Mac 설정 변경하기

macOS에서 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「TCP/IP」를 열고 기존 설정을 기록한 뒤, 표에 따라 테스트 주소와 서브넷 마스크, 「라우터」 주소를 입력합니다. 「DNS」 탭에는 192.168.10.2를 입력하세요. 주소 충돌을 피하려면 먼저 테스트 주소가 DHCP 풀 범위 밖에 있는지 또는 예약된 주소인지 확인합니다.

전체 네트워크에 적용할 때는 메인 라우터의 DHCP에서 옵션 3(기본 게이트웨이)과 옵션 6(DNS 서버)을 보조 라우터 주소로 지정할 수 있습니다. 일부 가정용 라우터는 두 옵션을 따로 설정할 수 없으므로, 이 경우 단말별 설정을 유지하는 편이 되돌리기 쉽습니다. DHCP 설정을 바꾼 뒤에는 단말에서 임대 주소를 갱신해야 하며, 기존 임대 주소가 즉시 모두 바뀌지는 않습니다.

CPU 아키텍처와 리소스 여유 확인하기

라우터에 설치하는 것은 Linux 커널 프로그램이지 macOS 앱 설치 파일이 아닙니다. 먼저 SSH로 시스템 정보를 확인한 뒤 mihomo 릴리스에서 아키텍처에 맞는 파일을 선택하세요. “64비트 프로세서”라는 이유만으로 판단하면 안 됩니다. 프로세서가 64비트를 지원하더라도 현재 펌웨어의 사용자 공간이 64비트라는 뜻은 아닙니다.

ubus call system board
uname -m
getconf LONG_BIT
free -m
df -h
cat /etc/openwrt_release

경량 펌웨어에는 getconf가 없을 수 있으므로 시스템 보드 정보와 펌웨어 타깃을 함께 확인하세요. 일반적으로 x86_64는 AMD64, aarch64는 ARM64에 해당합니다. MIPS 기기는 엔디언, 명령어 집합, 부동소수점 규약도 구분해야 합니다. 실행 중 Exec format error가 발생하면 실행 권한을 반복해서 추가하기 전에 아키텍처부터 확인하세요.

권장 용량과 실제 사용량을 구분하기

• 메모리: 256 MB 기기는 신중하게 검토해야 합니다. 보통 512 MB 이상이면 규칙 세트, DNS 캐시, 동시 연결을 처리할 여유가 더 충분합니다. 이는 구성 계획을 위한 권장 사항이며 커널의 고정 최소 사양은 아닙니다.
• 저장 공간: /overlay의 여유 공간을 확인하세요. 커널과 규칙 데이터베이스, 업데이트 중 생성되는 이전·새 파일이 모두 공간을 차지하므로 압축 파일 크기만으로 계산하지 마세요.
• 프로세서: 프록시 암호화, 규칙 매칭, 다수의 연결은 모두 CPU를 사용합니다. 인터넷 회선이 1000 Mbps라고 해서 라우터가 프록시를 거친 뒤에도 같은 속도를 낼 수 있는 것은 아닙니다.

설치 후 mihomo -v를 실행해 실제 버전을 기록하세요. 문제를 조사할 때는 펌웨어 버전, 트래픽 처리 방식, 규칙 규모도 함께 기록합니다. 유휴 상태, 구독 적용 후, 10분간 전송한 뒤의 세 시점에서 top과 free -m을 확인하세요. 프로세스의 상주 메모리와 시스템 가용 메모리를 살펴보고, Linux의 캐시 메모리를 단순히 메모리 누수로 판단하지 마세요.

커널, 투명 프록시, DNS를 따로 설정하기

OpenWrt 22.03 이후의 일반적인 버전은 기본적으로 firewall4를 사용하며 nftables로 방화벽 규칙을 생성합니다. 오래된 가이드의 iptables 명령을 범용 설정처럼 그대로 붙여 넣으면 안 됩니다. 플러그인을 사용한다면 지원하는 방화벽 백엔드를 확인하고, 직접 설정한다면 현재 펌웨어에서 TProxy 또는 TUN에 필요한 모듈을 사용할 수 있는지 확인하세요.

설정을 확인한 뒤 단말 트래픽 처리하기

실행 설정과 리소스 디렉터리를 고정된 경로에 저장하세요. 아래 명령은 커널이 /usr/bin/mihomo에 설치되고 설정 파일이 /etc/mihomo/config.yaml에 있다고 가정합니다. 실제로 해당 경로를 사용하는 경우에만 실행하세요.

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

설정 검사가 성공해도 설정을 불러올 수 있다는 뜻일 뿐, 구독 갱신이나 노드 연결, 투명 프록시 작동까지 보장하지는 않습니다. 선택한 정책 그룹과 최종 기본 규칙, 노드 서버 도메인의 DNS 조회 가능 여부도 확인하세요. 구독 URL에는 인증 정보가 포함되는 경우가 많으므로 로그나 스크린샷을 공유하기 전에 전체 주소를 가리세요.

포트별 용도를 구분하기

mixed-port: 7890을 설정했다면 7890은 앱이 명시적으로 연결하는 HTTP/SOCKS 혼합 프록시 포트입니다. tproxy-port: 7893을 설정했다면 7893은 투명 프록시 전달 규칙이 사용하는 포트입니다. 둘 다 변경 가능한 예시이며 커널을 실행한다고 반드시 열리는 포트는 아닙니다. 7890만 열어서는 LAN 트래픽이 자동으로 프록시를 거치지 않습니다.

TUN은 가상 네트워크 인터페이스이므로 기기 지원과 권한, 라우팅 설정이 필요합니다. 자동 라우팅을 켜더라도 LAN 포워딩, 방화벽 영역, DNS 진입 경로를 확인해야 합니다. TUN이 보조 라우터 설정을 모두 자동으로 끝내 준다고 보면 안 됩니다. TProxy는 보통 트래픽에 표시를 붙이고 정책 라우팅을 사용해 가로챈 데이터를 로컬 프록시가 처리하도록 합니다.

DNS 요청이 한 방향으로 흐르도록 구성하기

일반적인 구성에서는 단말이 보조 라우터의 53번 포트로 요청을 보내고, dnsmasq가 이를 받은 뒤 mihomo의 로컬 DNS 리스너(예: 127.0.0.1:1053)로 전달합니다. 1053은 실제 설정값과 일치해야 합니다. dnsmasq가 mihomo로 전달한 요청을 mihomo가 다시 dnsmasq로 넘겨 순환하지 않도록 하세요.

• fake-ip 사용: 커널이 단말에 도메인 매핑용 주소를 반환하고 이후 매핑 정보를 바탕으로 도메인을 복원합니다. 흔히 사용하는 주소 풀은 198.18.0.0/16이며 기존 네트워크나 VPN에서 사용하는 대역과 겹치지 않아야 합니다.
• 노드 도메인 조회: 프록시 서버 자체의 도메인을 조회할 수 있도록 부트스트랩 DNS 경로를 유지하세요. 프록시에 연결해야만 프록시 서버의 주소를 조회할 수 있는 순환 의존성을 피해야 합니다.
• 암호화 DNS 확인: 브라우저에서 직접 설정한 DoH는 LAN DNS를 우회할 수 있습니다. 이 경우 도메인 기반 규칙과 fake-ip 매핑이 예상과 다르게 작동할 수 있으므로 테스트할 때 DNS 경로를 먼저 통일하세요.

보조 라우터가 fake-ip를 반환했다면 단말의 연결도 같은 커널을 계속 거쳐야 합니다. DNS만 보조 라우터를 가리키고 게이트웨이는 메인 라우터를 가리키면, 메인 라우터가 해당 매핑 주소를 처리하지 못할 수 있습니다. 도메인은 조회되지만 웹페이지가 열리지 않는 문제가 흔히 발생합니다.

단일 인터페이스 라우팅, IPv6, 보안 경계 다루기

단일 인터페이스 보조 라우터는 주요 LAN 인터페이스가 하나뿐이라 패킷 수신과 메인 라우터로의 전송이 같은 인터페이스를 거칠 수 있습니다. 직접 연결 트래픽은 보조 라우터를 거쳐 나가지만 응답은 메인 라우터가 단말에 바로 전달해 비대칭 경로가 생길 수 있습니다. 보조 라우터에서 SNAT가 필요한지는 연결 추적, 방화벽, 상위 라우팅을 고려해 판단하세요.

일부 구성에서는 전달 트래픽에 SNAT 또는 masquerade를 적용해 메인 라우터에 보이는 출발지 주소를 보조 라우터 주소로 바꿉니다. 그러면 응답도 보조 라우터를 거치게 할 수 있습니다. 단일 인터페이스 구성 일부를 단순화할 수 있지만 상위 라우터에서는 여러 단말이 하나의 출발지로 보입니다. 모든 기기에서 “LAN 영역 주소 위장”을 반드시 켜야 하는 것은 아닙니다.

IPv4를 바꿨다면 IPv6도 별도로 확인하기

메인 라우터가 RA(라우터 광고)로 단말에 IPv6 기본 경로를 계속 알릴 수 있습니다. IPv4 게이트웨이만 바꿔서는 IPv6 트래픽을 제어할 수 없습니다. 사용 중인 구성에서 IPv6도 함께 처리하는지, 해당 DNS와 포워딩 규칙을 제공하는지 확인하세요. 테스트 단말에서 IPv6를 잠시 비활성화해 비교한 뒤 정식 듀얼 스택 설정을 결정할 수 있습니다.

관리 포트를 신뢰할 수 있는 네트워크로 제한하기

• 프록시 포트, DNS 서비스, 제어 인터페이스를 공용 인터넷에 노출하지 마세요.
• LAN에서 프록시를 제공해야 한다면 allow-lan, 리스닝 주소, 클라이언트 인증, 방화벽의 접속 출발지 제한을 확인하세요.
• 제어 API는 가급적 루프백 주소에서만 수신하도록 설정하세요. 원격 패널이 필요하다면 강력한 비밀번호를 설정하고 접속 가능한 관리 단말을 제한하세요.
• SSH 세션에서만 프로세스를 실행하지 말고 OpenWrt의 procd 서비스나 플러그인 자체 서비스 관리 기능으로 지속 실행되도록 설정하세요.

연결 순서에 따라 인터넷 장애와 트래픽 분기 문제 해결하기

문제를 해결할 때는 한 번에 한 항목만 변경하세요. 먼저 주소와 라우팅을 확인하고, 다음으로 DNS를 살펴본 뒤 규칙과 노드를 점검합니다. 구독 변경, 게이트웨이 수정, 방화벽 재구성을 한꺼번에 하면 어떤 단계가 영향을 줬는지 파악하기 어렵습니다.

테스트용 Mac에서 네트워크 진입 경로 확인하기

route -n get default
scutil --dns
ping -c 3 192.168.10.2
dig @192.168.10.2 example.com
curl -I --connect-timeout 10 https://example.com

기본 IPv4 게이트웨이는 예시의 192.168.10.2여야 합니다. DNS 조회가 계속 시간 초과되지 않고 응답하는지도 확인하세요. 시스템 DNS 출력에는 VPN 전용 검색 도메인이 포함될 수 있으므로 실제 사용 중인 네트워크 서비스와 함께 살펴봐야 합니다. 특정 대상이 ping에 응답하지 않는다고 인터넷 연결이 끊겼다고 단정할 수는 없습니다. DNS와 HTTPS 결과도 확인하세요.

OpenWrt에서 포워딩과 로그 확인하기

ip route
ip rule
ip route show table all
logread | tail -n 80
nft list ruleset

아래 명령은 기존 규칙을 삭제하지 않고 상태를 확인하는 용도입니다. 예상한 기본 경로와 트래픽 마킹 관련 정책, LAN에서 대상 처리 체인으로 전달되는 경로가 있는지 살펴보세요. 규칙 출력에 LAN 주소나 서비스 정보가 포함될 수 있으므로 공유할 때는 문제 해결에 필요한 부분만 남기세요.

작은 요청은 정상이지만 대용량 파일 전송이 멈춘다면 MTU, 경로 MTU 탐색, 상위 PPPoE 캡슐화를 확인하세요. 처음부터 모든 인터페이스의 값을 억지로 같게 바꾸지 마세요. 전송 속도는 먼저 직접 연결 기준값을 측정한 뒤 같은 단말과 연결 방식으로 프록시 속도를 측정해야 합니다. 무선 신호 변화로 인한 차이를 커널 성능 문제로 오해하지 않도록 주의하세요.

되돌릴 방법을 마련한 뒤 적용 범위 넓히기

1. 초기 상태 저장. OpenWrt 설정을 백업하고 메인 라우터 주소와 DHCP 풀, 테스트 단말의 기존 자동 설정을 기록하세요.
2. 기본 기능 확인. 국내 직접 연결, 프록시가 필요한 연결, LAN 프린터와 NAS 접속이 모두 규칙에 맞게 작동하는지 확인하세요.
3. 재시작 후 상태 확인. 커널과 보조 라우터를 각각 재시작하고, Mac의 네트워크 연결을 끊었다가 다시 연결해 올바른 게이트웨이와 DNS를 사용하는지 확인하세요.
4. 보조 라우터 오프라인 상황 점검. 테스트 단말의 게이트웨이를 메인 라우터로 되돌리고 기존 DNS를 복원해 기본 인터넷 연결이 가능한지 확인하세요. fake-ip를 사용한다면 DNS 캐시를 비우거나 관련 앱을 다시 시작해야 합니다.
5. 단계적으로 적용. 먼저 소수의 기기만 추가한 뒤 DHCP 설정을 변경하세요. 메인 라우터의 관리 화면에 직접 연결할 수 있는 단말 한 대는 남겨 두세요.

같은 서브넷의 보조 라우터에는 기본적으로 장애 자동 전환 기능이 없습니다. 단말이 오프라인 상태의 보조 라우터를 기본 게이트웨이로 계속 사용하면, 메인 라우터가 작동 중이어도 자동으로 대신 처리하지 않습니다. 주소 계획과 DNS 경로, 서비스 자동 시작, 복구 절차를 함께 기록해 두면 커널 업데이트나 구독 변경 후 문제를 빠르게 찾을 수 있습니다.

Mac 한 대에서만 프록시를 사용한다면 데스크톱 클라이언트로 구독과 규칙을 먼저 확인하는 편이 간편합니다. TV나 게임 기기, 여러 단말에서 같은 정책을 공유해야 할 때 OpenWrt로 규칙을 옮기세요. 두 방식은 서로 다른 범위의 트래픽을 처리하므로 처음부터 가정 내 전체 네트워크를 변경할 필요는 없습니다.