1. 토폴로지부터: “게이트웨이만 바꿨다”가 실제로 의미하는 것
많은 글이 Windows·macOS 클라이언트나 WSL2에 초점을 맞추지만, 사이드라우터는 보통 메인 공유기(상위 게이트웨이) 아래에 두 번째 L3 장치로 붙습니다. 이때 내부 단말의 기본 게이트웨이를 사이드라우터 LAN IP로 바꾸면, 단말→사이드라우터 구간은 의도대로 흐르지만, 사이드라우터→인터넷 구간에서 NAT·정책 라우팅·방화벽 FORWARD 중 하나라도 비면 “밖으로 나가는 패킷”이 통째로 사라집니다. 먼저 사이드라우터가 WAN(또는 상위 LAN) 쪽에서 기본 경로를 제대로 받는지, 그리고 상위 공유기가 사이드라우터 뒤 서브넷을 정적 라우트로 돌려줄 필요가 있는지(한 ARM 기기만 게이트웨이로 쓰는 이중 NAT면 종종 생략)부터 확인하세요.
ping 1.1.1.1은 되는데 단말에서는 안 되면, 문제는 거의 항상 FORWARD·NAT·rp_filter 쪽에 있습니다.
2. 게이트웨이·라우팅: 단말이 정말 “그 장치”를 쓰는가
DHCP로 내려준 게이트웨이가 의도한 사이드라우터인지, IPv4만 바꾸고 IPv6는 여전히 상위 공유기 RA를 타는지부터 봅니다. Android·Windows는 개별 앱 DNS(Private DNS, DoH)로 우회하기 쉬워 “IP는 우회되는데 이름만 직통”처럼 보이기도 합니다. 라우팅 테이블에서 기본 경로(default via)가 사이드라우터 한 줄로 깔끔한지, VPN 클라이언트가 더 높은 메트릭으로 삽입한 경로가 없는지도 함께 점검하세요.
2.1 상위 공유기와의 관계
사이드라우터 WAN이 상위 LAN의 “또 다른 클라이언트”라면, 상위에서 DMZ나 포트 포워딩이 필요한 경우는 적고, 대신 이중 NAT 아래에서 포트 충돌·UPnP 이슈가 생깁니다. 반대로 브리지에 가깝게 한 장치만 게이트웨이로 쓰는 구조라면, 상위에 정적 라우트(사이드라우터 뒤 서브넷 → 사이드라우터 WAN IP)가 없을 때 “사이드라우터 자체는 인터넷 되는데 뒤 단말만 안 된다”는 패턴이 흔합니다. 운영체제마다 ip route·ip -6 route 출력 형식은 다르지만, “응답 패킷이 돌아올 경로가 있는가”를 같은 기준으로 보면 됩니다.
3. IP 포워드·비대칭 라우팅: 커널이 중간에서 버리지 않게
Linux 계열 소프트 라우터에서는 net.ipv4.ip_forward=1(필요 시 IPv6도)이 꺼져 있으면 FORWARD 체인에 규칙이 있어도 패킷이 앞에서 막힙니다. 또한 rp_filter가 엄격하면, 멀티 홈이나 정책 라우팅을 쓸 때 정상 트래픽이 비대칭으로 보여 드롭될 수 있습니다. 일시적으로 tcpdump -i any icmp로 단말 ping이 사이드라우터 WAN·LAN 어느 인터페이스에 찍히는지 보면, “들어오기만 하고 나가기가 없다” vs “나갔는데 응답이 다른 인터페이스로 돌아와서 버린다”를 빠르게 가릅니다.
4. nftables(·iptables-nft): NAT와 마스커레이드
단말 IP 대역이 WAN 쪽과 다르면, 사이드라우터는 보통 SNAT/MASQUERADE로 출발지 주소를 WAN 인터페이스 IP로 바꿉니다. nftables를 쓰는 배포판에서는 nft list ruleset으로 nat 테이블의 postrouting 훅을 확인하고, iptables 레거시 스크립트를 쓰더라도 실제로는 nft 백엔드로 변환되는 경우가 많습니다. 규칙이 “특정 소스 대역만” 허용되도록 좁혀져 있으면 일부 단말만 나가고 나머지는 침묵 실패하는 식으로 갈립니다. FORWARD 기본 정책이 DROP인데 established,related 허용이 빠져 있으면, NAT는 되어도 응답이 막혀 “전부 타임아웃”처럼 보입니다.
# Example: inspect active nftables ruleset (read-only)
nft list ruleset클라우드 이미지처럼 firewalld·ufw가 동시에 켜진 환경에서는 사용자가 추가한 raw nft 규칙과 충돌하기도 합니다. 한 번에 하나의 방화벽 스택을 “진실 공급원”으로 정하고 나머지는 끄는 편이 디버깅에 유리합니다.
5. Clash 쪽: TUN vs 리다이렉트·mixed-port
투명 프록시를 기대하면서 실제로는 mixed-port만 열어 두고 단말에 프록시 PAC를 안 넣은 경우가 흔합니다. “게이트웨이만”으로 끝내려면 보통 TUN 모드로 OS 라우팅에 붙이거나, eBPF/redirect 계열로 커널에서 가로채야 합니다. TUN을 켰다면 인터페이스가 올라왔는지, 자체 라우팅이 메인 테이블과 충돌하지 않는지, 그리고 DNS가 코어로 들어오게 listen 포트가 열려 있는지를 봅니다. Windows 단말에서 비슷한 증상은 TUN·방화벽 글의 순서가 그대로 참고되지만, 본문은 Linux 라우터 전제입니다. 설정 개념 전반은 Clash 문서와 맞춰 읽는 것이 좋습니다.
5.1 권한과 capability
TUN 디바이스 생성·라우팅 조작은 루트나 CAP_NET_ADMIN이 필요합니다. systemd 서비스로 돌릴 때는 유닛 예시처럼 사용자·Capability를 명시적으로 맞추지 않으면 “수동 실행은 되는데 서비스만 실패”하는 패턴이 나옵니다.
6. DNS 가로채기: “웹은 되는데 위치만 이상하다”
IP 레벨 프록시가 정상인데도 넷플릭스 지역·검색 결과만 국내로 남으면, 트래픽이 아니라 질의가 여전히 통신사 DNS로 가는 경우가 많습니다. 대응은 (1) 단말 DHCP로 사이드라우터의 DNS 서버만 내려주기, (2) 53/tcp·udp를 로컬 리졸버로 DNAT, (3) Clash의 DNS 섹션에서 fake-ip·redir-host 정책을 LAN 규모에 맞게 정렬하기, 순으로 좁힙니다. DNS over TLS·HTTPS로 직접 나가는 단말은 53번 가로채기만으로는 부족할 수 있어, “앱별로 DoH 고정”인지 여부를 의심해야 합니다. fake-ip 필터와 스니퍼 설정은 이 단계에서 같이 봅니다.
7. 일부 기기만 직통일 때: IPv6·하드코딩·세그먼트
같은 SSID라도 기기마다 IPv6가 켜져 있으면 AAAA 응답을 타고 상위 공유기로 빠져나가 “일부만 우회”처럼 보일 수 있습니다. IoT·스마트 TV는 하드코딩 DNS나 콘텐츠 CDN에 직접 붙으려 해서, PC에서는 되는데 TV만 실패하는 식으로 갈립니다. VLAN이나 게스트 Wi-Fi를 쓰면 사이드라우터가 기본 게이트웨이가 아닌 세그먼트로 붙어 있을 수 있으니, 스위치·AP의 트렁크·PVID 설정도 함께 의심합니다.
8. 증상별 빠른 대응 표
아래는 현장에서 자주 쓰는 “먼저 어디를 볼지” 정리입니다. 실제 명령·인터페이스 이름은 배포판에 맞게 바꾸면 됩니다.
| 증상 | 의심 지점 | 먼저 할 일 |
|---|---|---|
| 사이드라우터만 인터넷 됨 | 상위 정적 라우트·이중 NAT | 상위에 뒤쪽 서브넷 경로 추가, 단말 traceroute |
| ping IP는 되고 이름만 실패 | DNS 우회·DoH | 단말 DNS 설정, 53 리다이렉트·Clash DNS |
| 간헐적 끊김 | rp_filter·정책 라우팅 | dmesg·tcpdump로 비대칭 여부 확인 |
| HTTP만 됨 | 프록시 모드 혼동·포트 제한 | TUN·FORWARD·NAT 일관성, mixed-port만 쓰는지 확인 |
9. 요약
사이드라우터에서 Clash로 투명 프록시를 기대할 때는 “단말 게이트웨이” 한 줄이 아니라, 포워딩·nftables NAT·코어의 TUN·DNS까지 한 경로로 묶어야 합니다. iptables와 nftables 명령이 섞여 보이면 실제 적용 스택을 먼저 단일화하고, 증상별로 표를 따라가면 같은 구독이라도 “코어는 살아 있는데 LAN만 죽는” 상황을 빨리 가릴 수 있습니다. 개별 PC·모바일 클라이언트는 공식 다운로드로 받아 동일 정책을 맞추면, 집 안·밖 전환 시 혼선이 줄어듭니다.
오픈 소스 저장소는 빌드·이슈 확인용으로 두고, 일상적인 설치 패키지는 사이트 정책에 맞추는 편이 운영에 유리합니다. 라우터 한 대로 끝내기 어렵다면, 우선 사이드라우터에서 기본 경로와 NAT만 완전히 검증한 뒤 Clash 고급 옵션을 켜는 순서가 가장 비용 대비가 좋습니다.