사이 게이트웨이 토폴로지와 OpenWrt 대안이 갖는 의미

“사이 라우터” 혹은 “사이 게이트웨이”는 메인 공유기의 펌웨어를 바꾸지 않고, LAN에 추가로 붙은 Linux 소호기가 기본 게이트웨이 역할을 일부 장치에만 맡는 구성을 말합니다. 스위치 뒤에 한 줄로 붙여도 되고, 무선 브리지로 붙여도 되지만, 핵심은 클라이언트가 기본 경로를 Linux 호스트 IP로 향하게 만든다는 점입니다. 이미 공유기에서 전부를 끝내고 싶다면 OpenWrt·OpenClash 게이트웨이 글의 축이 더 가깝고, 본 글은 “범용 Linux + Clash TUN + nftables”라는 독립 재현 경로에 초점을 둡니다.

TUN은 “앱이 프록시를 존중해야 한다”는 전제를 줄이고, 커널 라우팅과 정책 라우팅에 가깝게 붙습니다. 동작 원리·옵션 트레이드오프는 TUN 모드 심화를 먼저 읽고 오면 이후 단계가 훨씬 덜 추상적으로 느껴집니다. 한 대의 Ubuntu/Debian 계열에서 코어를 서비스로 고정하는 절차는 Ubuntu TUN·systemd 가이드와 겹치므로, 여기서는 다른 LAN 장치가 붙는 게이트웨이 관점의 포워딩·방화벽·클라이언트 DHCP를 보강합니다.

ℹ 용어: 본문의 LAN_IF는 사이 호스트가 내부망에 붙은 이더넷(예: enp2s0), WAN_IF는 상위 라우터 방향 인터페이스(단일 NIC 구성이면 동일일 수 있음)로 읽으면 됩니다. 실제 이름은 ip link로 확인하세요.

Linux 호스트 준비: 고정 IP와 커널 포워딩

클라이언트가 게이트웨이로 삼을 주소가 부팅마다 바뀌면 운영이 지치므로, 사이 호스트는 DHCP 예약이나 정적 IPv4로 고정하는 편이 안전합니다. 메인 라우터가 192.168.1.1이고 대역이 192.168.1.0/24라면, 사이 호스트는 예를 들어 192.168.1.2/24로 두고 기본 게이트웨이는 여전히 192.168.1.1을 가리키게 두는 식이 흔합니다(호스트 자신의 인터넷 출구는 메인 라우터를 경유).

다른 장치의 IP 패킷을 중계하려면 커널에서 IPv4 포워딩이 켜져 있어야 합니다. 재부팅 후에도 유지되게 sysctl.d에 박아 두세요.

sysctl 예시 (영구 적용 경로는 배포판에 맞게) 
# /etc/sysctl.d/99-ipforward.conf
net.ipv4.ip_forward=1

적용은 sudo sysctl --system 또는 재부팅으로 확인합니다. IPv6를 같이 쓰는 집이라면 RA·추가 주소가 섞이며 “절반만 터널” 같은 증상이 나기도 하므로, IPv6 듀얼 스택·DNS 글과 함께 범위를 정하는 것이 좋습니다.

Clash 측: TUN·LAN 허용·DNS 정렬

LAN의 다른 장치에서 오는 연결을 코어가 받으려면 바인드·LAN 허용 계열 옵션을 빼먹지 않는 것이 중요합니다. 증상은 “호스트 자신의 브라우저만 되고 스마트폰은 안 된다”처럼 잘게 갈립니다. 방화벽·서브넷·AP 격리까지 한 번에 점검하는 흐름은 LAN 공유·방화벽·바인드 글과 거의 같은 축입니다.

tun: 블록은 사용 중인 Clash Meta/Mihomo 버전 문서를 기준으로 enable, stack, auto-route, auto-detect-interface를 맞춥니다. DNS는 fake-ip·fallback 조합에서 LAN 게이트웨이가 더 민감해질 수 있으니, Meta DNS nameserver·fallback과 fake-ip와 LAN 라우터를 교차 확인하세요. 규칙 파일 쪽은 규칙 라우팅 모범 사례에서 “로컬 대역 DIRECT” 같은 안전망을 먼저 두는 패턴을 권합니다.

개념 정렬용 YAML 발췌(키 이름은 버전에 맞게 조정) 
bind-address: '*'
allow-lan: true

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
⚠ SSH로만 붙는 박스라면: TUN·정책 라우팅 실험은 세션을 끊을 수 있습니다. 콘솔·KVM·ILO를 확보하거나, 먼저 벤치 네트워크에서 검증하세요.

nftables: 포워드 허용과 SNAT(출구) 정리

Linux가 “라우터처럼” 패킷을 넘기려면 filter FORWARD 경로가 막혀 있지 않아야 하고, 상위 라우터와의 주소 관계에 따라 POSTROUTING SNAT/MASQUERADE가 필요할 수 있습니다. 배포판 기본 규칙이 policy drop이면 “포워딩은 켰는데 카운터만 안 오른다”가 흔합니다. 아래는 최소 예시이며, 실제 정책·인터페이스 이름에 맞게 조정해야 합니다.

nftables 초안 (주석은 영문) 
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    # management: replace with your admin CIDR
    ip saddr 192.168.1.0/24 tcp dport 22 accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "LAN_IF" oifname "WAN_IF" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "WAN_IF" masquerade
  }
}

단일 NIC만 있고 브로드캐스트 도메인이 동일한 “한 팔(one-arm)형” 구성이라면, LAN_IF와 WAN_IF가 같을 수 있습니다. 이 경우에도 커널 포워딩·conntrack·Clash 쪽 라우팅이 어떻게 겹치는지를 nft monitor, sysctl net.netfilter.nf_conntrack_count, ip -4 route로 나란히 보는 것이 안전합니다. ufw/nft 둘 다 켜 두면 규칙이 이중으로 겹치기 쉬우니, 한 축으로 단순화하는 편이 재현에 유리합니다.

클라이언트: DHCP 게이트웨이·수동 설정

“집 전체”를 한 번에 옮기고 싶다면 메인 라우터의 DHCP 옵션에서 기본 게이트웨이를 사이 호스트로 바꾸는 방법이 있습니다. 다만 이 경우 메인 라우터 자체 관리 트래픽까지 의도치 않게 흔들릴 수 있으니, 테스트 VLAN·별도 SSID·소수 장치만 수동 설정으로 시작하는 것을 권합니다. 안드로이드·아이폰·PC 각각에서 “기본 경로만 바꾸고 DNS는 메인 라우터”처럼 쪼개는 것도 가능하지만, Clash가 DNS까지 관여하는 구성이면 DNS 글과 충돌이 없는지 함께 확인해야 합니다.

수동 설정 시 확인할 값은 세 가지입니다. (1) IPv4 주소/프리픽스 길이, (2) 기본 게이트웨이 = 사이 호스트 LAN IP, (3) DNS를 사이 호스트·메인 라우터·공용 DNS 중 어디로 둘지입니다. “게이트웨이만 바꿨는데 특정 앱만 느려진다”면 분할 라우팅이 아니라 MTU·DNS·IPv6 우선 쪽을 의심하세요.

검증 순서와 흔한 끊김 포인트

첫 단계는 사이 호스트에서 ping으로 메인 라우터·인터넷을 확인하는 것입니다. 다음으로 LAN 클라이언트에서 ping 사이호스트IP, ping 메인라우터IP, ping 1.1.1.1을 순서대로 찍어 “어디에서 끊기는지”를 고정합니다. Clash 대시보드나 로그에서 해당 클라이언트의 플로우가 보이면 TUN 경로까지는 올라온 것입니다. TLS·타임아웃이면 연결 로그·timeout·TLS 글의 분리 절차를 그대로 가져와도 좋습니다.

nft list ruleset에서 카운터가 오르는지, cat /proc/sys/net/ipv4/ip_forward가 1인지, ip rule list에 Clash가 넣은 정책 라우팅이 과도하게 겹치지 않는지를 체크리스트로 적어 두면 재부팅 이후에도 같은 순서로 복구할 수 있습니다.

오픈소스 참고와 설치 패키지 경로

Mihomo/Clash Meta는 라이선스·이슈 트래커·소스 코드를 GitHub에서 확인할 수 있습니다. 다만 일반 사용자에게 “클라이언트 설치 파일을 어디서 받을지”는 사이트의 다운로드 페이지를 기본으로 두고, GitHub 릴리스는 변경 기록·검증용으로 분리하는 편이 혼선이 적습니다.

맺음말

사이 게이트웨이는 “OpenWrt 한 방”보다 손이 가지만, 범용 Linux에 익숙한 사용자에게는 업데이트·백업·모니터링을 자기 도구로 풀 수 있다는 장점이 있습니다. 본 글의 핵심은 포워딩 sysctl → nftables FORWARD/NAT → Clash TUN·allow-lan·DNS 정렬 → 클라이언트 게이트웨이를 한 줄기로 묶는 것이고, 세부 튜닝은 배포판·커널·코어 버전에 따라 달라집니다. 장기 운영 시에는 systemd 유닛으로 부팅 순서를 고정해 두면 재현성이 크게 좋아집니다.

데스크톱 클라이언트는 GUI 편집이 강점이고, 사이 호스트는 “항상 켜진 규칙 엔진”에 가깝습니다. 둘 다 같은 정책 철학을 쓰되 UX는 다르다는 점에서, 다른 플랫폼과 비교해 보고 싶다면 Clash와 VPN의 차이 글도 참고해 보세요. 마지막으로, 설치 경로 혼선을 줄이려면 → Clash를 무료로 내려받아 데스크톱에서 먼저 규칙을 검증한 뒤 동일한 YAML을 사이 호스트에 옮기는 흐름이 가장 안전합니다.