OpenWrt 배 라우터에서 mihomo: 투명 게이트웨이와 DNS 리다이렉트 단계별 설정

어떤 분께 맞는 글인가요?

이미 x86 미니 PC나 Raspberry Pi 등에 OpenWrt를 올려 두었거나, 곧 배(旁) 라우터 형태로 같은 LAN에 붙일 계획이 있는 경우에 맞춰 썼습니다. 목표는 단순히 “Clash 소개”가 아니라, 스마트폰·PC·TV가 별도 프록시 설정 없이 기본 게이트웨이와 DNS만으로 mihomo 코어를 타게 만들고, DNS 오염이나 분할 규칙과 실제 경로가 어긋나는 상황을 줄이는 데 있습니다. 데스크톱에 Clash 클라이언트만 쓰던 경험과 달리, 라우터 층에서는 DHCP·NAT·방화벽 리다이렉트가 한 번에 얽히므로 순서를 지키는 것이 중요합니다.

패널 이름은 배포판마다 다릅니다. OpenClash·ShellCrash·직접 빌드한 mihomo 바이너리 모두 핵심은 같습니다. 이 글에서는 UI 대신 재현 가능한 설정 축(IP·포트·방화벽·DNS)을 기준으로 설명합니다. YAML 규칙 자체는 규칙 분할 가이드와, TUN·DNS 개념은 TUN 모드 가이드를 함께 보시면 흐름이 이어집니다.

토폴로지를 먼저 고릅니다

가장 흔한 구성은 메인 공유기(예: 192.168.1.1)가 ISP에 연결되고, 보조 OpenWrt(예: 192.168.1.2)가 같은 /24 대역의 LAN 포트 하나로만 메인 스위치에 붙는 형태입니다. 이때 보조 장비는 “WAN으로 다시 나가는” 이중 NAT보다, 같은 브로드캐스트 도메인에 떠 있는 게이트웨이 역할에 가깝게 두는 편이 관리가 쉽습니다. 메인 쪽 DHCP를 끄고 보조에서만 주소를 나눠 주거나, 메인은 주소만 나눠 주고 옵션 3·6(기본 게이트웨이·DNS)만 보조로 넘기는 식으로 나눌 수 있습니다. 전자는 메인 펌웨어에서 DHCP를 끌 수 있을 때, 후자는 메인이 커스텀 DHCP 옵션을 지원할 때 현실적입니다.

어느 쪽이든 원칙은 같습니다. 단말이 보는 기본 경로의 다음 홉이 보조 OpenWrt이고, DNS 질의도 최종적으로 mihomo의 리스너나, mihomo가 지정한 업스트림으로 가야 fake-ip·DOMAIN-SUFFIX 분기가 기대대로 동작합니다. TV·게임기처럼 프록시 UI가 없는 장치까지 포함하려면 이 축을 먼저 맞춰야 합니다.

참고: 메인 공유기가 반드시 남아 있어야 ISP VLAN·IPT 멀티캐스트 같은 특수 기능을 유지할 수 있습니다. 보조 장비를 게이트웨이로 쓰더라도, 물리 배선상 메인의 LAN 브리지에 붙어 있어야 하는 경우가 많습니다.

준비: OpenWrt 기본 네트워크 고정

보조 장비의 LAN 브리지에 정적 IPv4를 부여합니다. 예를 들어 주소 192.168.1.2, 마스크 255.255.255.0, 게이트웨이는 메인 192.168.1.1, DNS는 설정 중에는 공용 값이나 메인이 허용하는 값으로 두고 연결을 확인합니다. 방화벽 존에서 LAN이 accept인지, 보조 장비에서 메인으로 ping이 나가는지 먼저 검증하세요. 이 단계에서 인터넷이 안 되면 이후 mihomo를 켜도 원인 분리가 어렵습니다.

같은 서브넷에 두 대의 DHCP 서버가 뜨지 않게 조정합니다. 메인과 보조가 동시에 주소를 뿌리면 단말마다 게이트웨이가 달라져 증상이 무작위로 보입니다. 한쪽을 끄거나, 메인에서 할당 범위를 비우고 보조로만 옮기는 등, 집 안에서 단일 DHCP 권한을 확보하는 것이 첫 번째 안전장치입니다.

DHCP로 “전체 게이트웨이”를 보조로 보내기

OpenWrt의 dnsmasq 기반 DHCP에서 옵션 3에 보조 장비 자신의 IP를 넣습니다. 그러면 새로 임대받는 단말은 기본 라우트가 보조를 향합니다. 이미 임대 중인 기기는 재부팅하거나 임대를 갱신해야 하므로, 작업 직후에는 Wi-Fi 재연결이나 임대 갱신을 안내하는 것이 좋습니다. 고정 IP를 쓰는 NAS 등은 수동으로 기본 게이트웨이와 DNS를 보조로 바꿔 줘야 같은 정책을 탑니다.

메인 공유기만 건드려야 한다면, 메인 DHCP에 커스텀 옵션으로 3,192.168.1.2와 6,192.168.1.2 형태를 넣는 방법을 우선 확인합니다. 펌웨어가 막혀 있으면 결국 보조에서 DHCP를 받는 구조로 물리 포트를 재배선하는 편이 낫습니다. 이 글의 나머지는 “단말의 게이트웨이가 이미 보조 OpenWrt”라고 가정하고 진행합니다.

DNS 리다이렉트와 오염 방지

일부 단말은 하드코딩된 DNS(예: 구글 공용 주소)로 직접 질의합니다. 보조 게이트웨이에서 목적지 53/TCP·UDP를 mihomo가 듣는 DNS 포트로 DNAT하거나, dnsmasq의 server 지시로 상류를 mihomo에 붙이는 방식을 택합니다. OpenWrt 관례상 iptables-nft 또는 LuCI의 방화벽 포트 전달으로 같은 효과를 낼 수 있습니다. 중요한 점은 “단말이 어떤 IP로 보내든 최종적으로 mihomo의 DNS 스택이 개입한다”는 것을 보장하는 것입니다.

mihomo 설정에서 enhanced-mode나 fake-ip를 쓸 때는, LAN에 있는 카메라·NAS가 로컬 이름으로만 붙는 경우 fake-ip-filter에 해당 도메인을 넣어 직접 해석하게 만드는 식의 예외가 필요합니다. 스트리밍 호스트가 규칙에 안 잡히는 문제는 Sniffer 관련 글의 순서와 맞물리므로, DNS만 맞추고도 앱이 이상하면 Sniffer·규칙 우선순위를 함께 보세요.

팁: dnsmasq의 rebind protection이 사설 응답을 막으면 mihomo의 fake-ip 응답이 떨어질 수 있습니다. 해당 넌스가 보이면 일시적으로 완화하거나, mihomo 리스너를 127.0.0.1에만 두고 로컬에서 dnsmasq가 포워딩하도록 분리하는 패턴도 흔합니다.

투명 프록시(REDIRECT·TPROXY) 개요

단말이 SOCKS나 HTTP 프록시를 모를 때, 라우터는 PREROUTING에서 목적지 80·443 같은 TCP 포트를 mihomo의 redir-port로 넘깁니다. UDP까지 동일한 정책이 필요하면 TPROXY와 라우팅 표 기반 정책이 추가로 필요해 난이도가 올라갑니다. 가정용이면 우선 TCP 위주로 안정화한 뒤 UDP를 확장하는 전략이 부담이 적습니다. OpenClash류 패널은 이런 규칙을 생성해 주지만, 충돌 시에는 LuCI의 방화벽 사용자 규칙과 실제 nftables 테이블을 대조해 중복이 없는지 확인하세요.

mihomo 쪽에서는 tun 기반으로 전체 스택을 잡는 방법과, pure redir로 L3 트래픽만 넘기는 방법이 갈립니다. 라우터 자원이 빡빡하면 redir 위주가 부담이 덜한 경우가 많고, TUN은 DNS·ICMP까지 한 번에 묶고 싶을 때 유리합니다. 어느 쪽이든 루프백 자기 자신으로 가는 트래픽이나 LAN 대역 직결은 예외에 넣지 않으면 관리 웹이 끊기거나 속도가 이상해질 수 있습니다.

권장 작업 순서(체크리스트)

  1. 보조 OpenWrt에서 메인까지 L2·L3 연결 확인(정적 IP, ping).
  2. DHCP 권한 단일화 후 옵션 3·6을 보조로 지정.
  3. mihomo 코어 기동, 구독·정책 그룹이 정상인지 로컬에서 curl로 확인.
  4. DNS가 보조를 향하는지 임의 단말에서 nslookup 또는 OS 도구로 검증.
  5. 투명 리다이렉트 규칙을 단계적으로 추가(먼저 TCP 443만 등).
  6. IPTV·은행 앱·사내 VPN 등 예외 대역을 DIRECT 규칙과 방화벽 예외에 반영.
  7. 재부팅 후에도 동일한지 스크립트 기동 순서(rc.local·procd)를 점검.

검증과 흔한 실패 패턴

게이트웨이는 보조인데 DNS만 메인에 남아 있으면, 브라우저는 프록시를 타는 것처럼 보여도 앱 스토어·OTA만 실패하는 식으로 갈라집니다. DNS와 게이트웨이를 같은 정책 축에 두었는지 다시 확인하세요. 반대로 DNS만 보조로 보내고 게이트웨이는 메인이면, SNI 기반 분기가 기대와 다르게 동작할 수 있습니다.

또 다른 흔한 원인은 IPv6입니다. RA로 글로벌 IPv6가 그대로 열리면 단말이 AAAA로 우회해 나가 버립니다. 당장은 메인에서 IPv6를 끄거나, 보조에서도 동일한 투명 정책을 적용할 때까지 IPv6 DNS를 함께 가로채는 계획을 세우는 편이 안전합니다. 장기적으로는 각 단말 OS 설정과 라우터 광고를 함께 맞춰야 합니다.

보안·합법 사용에 대한 짧은 주의

타인에게 할당된 네트워크에 동일 구성을 적용하면 정책 위반이 될 수 있습니다. 본인 소유 회선·장비에서만 시험하고, 구독 URL·바이너리는 신뢰할 수 있는 출처인지 확인하세요. 로그에 민감 정보가 남지 않게 보존 기간을 짧게 두는 것도 좋습니다.

마무리

OpenWrt 보조 장비에 mihomo를 올리고 투명 프록시와 DNS 리다이렉트를 순서대로 맞추면, PC·모바일·거실 단말까지 한 번에 같은 경로를 타게 만들 수 있습니다. 핵심은 DHCP 옵션으로 게이트웨이·DNS를 한 축으로 모으고, 방화벽에서 53·443 등을 코어가 듣는 포트로 안정적으로 넘기며, LAN·로컬 서비스 예외를 빠뜨리지 않는 것입니다. 세부 YAML은 데스크톱에서 검증한 뒤 라우터에 옮기면 롤백이 쉽습니다.

다른 플랫폼에서 이미 쓰던 정책을 그대로 이식하고 싶다면, 데스크톱용 클라이언트 생태계와의 차이를 직접 비교해 보는 것도 방법입니다. 규칙 표현이 풍부하고 DNS·TUN·redir를 한 코어에서 다루는 점에서 Clash·Mihomo 계열은 “집 전체를 한 정책으로 묶는다”는 목표와 잘 맞습니다.

라우터 밖의 단말에서 먼저 익숙해지고 싶다면 문서·튜토리얼을 참고한 뒤, 같은 구독을 보조 장비로 옮겨 보시길 권합니다. 준비가 되면 Clash를 무료로 다운로드해 데스크톱에서 정책을 다듬고, 안정화된 YAML을 OpenWrt 쪽 mihomo에 그대로 적용해 보세요. 투명 게이트웨이는 한 번 맞으면 이후 유지보수가 훨씬 수월해집니다.