obsidian/infra/network/beryl-ax.md at ebac715db54fc7a1136d676cf6e223e559d8e08c

Files

kaffa ebac715db5 infra/network: Beryl AX (GL-MT3000) 휴대용 라우터 문서 추가

GL.iNet 4.8.1 기본 설정에서 fw3 tailscale0 zone에 masq 옵션이
누락되어 LAN→tailnet forward 시 SNAT가 안 되는 문제와, dnsmasq
ts.net split-forward 미설정으로 MagicDNS 동작 안 하는 문제를
정리. 영구 UCI 설정과 Mac 측 /etc/resolver/ts.net + search domain
보정까지 포함.

2026-05-01 19:37:20 +09:00

4.8 KiB

Raw Blame History

title, updated, tags

title

updated

호스트 정보

항목	값
모델	GL.iNet GL-MT3000 (Beryl AX)
Board	`glinet,mt3000-snand` (mediatek/mt7981)
펌웨어	GL.iNet 4.8.1 (OpenWrt 21.02-SNAPSHOT base, kernel 5.4.211)
LAN	192.168.8.0/24 (gateway 192.168.8.1)
WAN	상위 공유기 뒤 더블 NAT (예: TP-Link 192.168.1.1 뒤 192.168.1.198)
Web UI	http://192.168.8.1 (GL.iNet, nginx 80/443) · http://192.168.8.1:8080 (LuCI/uhttpd)
SSH	`root@192.168.8.1`

용도: 출장/이동용 휴대 Wi-Fi 6 라우터. LAN을 만들고 tailscale subnet router로 동작시켜 노트북이 라우터에 붙기만 하면 tailnet에 접근 가능.

Tailscale

항목	값
Tailnet	`otter-buri.ts.net`
Hostname	`gl-mt3000`
Tailscale IP	100.98.170.28
AdvertiseRoutes	`192.168.1.0/24, 192.168.8.0/24`
RouteAll (accept-routes)	true
버전	tailscale 1.80.3 (펌웨어 내장)

tailscaled --port 41641 --state /etc/tailscale/tailscaled.state. tailnet admin console에서 advertise route 둘 다 approve 필요.

LAN → tailnet forward SNAT (필수 설정)

GL.iNet 4.8.1 기본 fw3 zone 정의에는 tailscale0에 masq 옵션이 없다. 그러면 LAN(192.168.8.0/24) → tailscale0 forward 트래픽이 SNAT되지 않아 source가 사설 IP(192.168.8.x) 그대로 tailnet에 나가고, peer가 응답 경로를 못 찾아 일부 노드와 통신이 끊긴다.

증상: LAN 클라이언트에서 ping 100.x.x.x가 timeout, 라우터 자체에서는 동일 peer 정상 통신. ICMP/TCP 모두 같은 패턴. peer가 라우터의 advertise route(192.168.8.0/24)를 OS routing table에 가지고 있는 경우(예: 같은 사용자의 다른 macOS)만 응답 가능.

영구 적용:

uci set firewall.tailscale0.masq='1'
uci add_list firewall.tailscale0.masq_src='192.168.8.0/24'
uci commit firewall
fw3 reload

검증:

iptables -t nat -L zone_tailscale0_postrouting -n -v
# MASQUERADE ... 192.168.8.0/24 룰이 박혀 있어야 함

MagicDNS split-forward

기본 설정에서 tailscale prefs의 CorpDNS: false이고 dnsmasq에도 ts.net forward 룰이 없어 LAN 클라이언트가 MagicDNS를 못 쓴다. ts.net 도메인만 100.100.100.100(Tailscale 내부 DNS proxy)로 보내는 split 방식이 GL.iNet의 기존 dnsmasq를 안 건드리고 가장 안전.

영구 적용:

uci add_list dhcp.@dnsmasq[0].server='/ts.net/100.100.100.100'
uci commit dhcp
/etc/init.d/dnsmasq restart

검증:

nslookup incus-jp1.otter-buri.ts.net 127.0.0.1
# → 100.109.123.1

100.100.100.100은 short name(incus-jp1)에 응답하지 않는다 — FQDN만 처리. short name은 클라이언트의 search domain으로 보완.

Mac 클라이언트 측 설정

Mac이 DNS를 hardcoded(예: 1.1.1.1, 8.8.8.8)로 쓰고 있으면 라우터 dnsmasq를 거치지 않아 ts.net 풀이가 안 된다. 정책을 바꾸지 않고 ts.net 도메인만 라우터로 보내려면:

sudo mkdir -p /etc/resolver
echo "nameserver 192.168.8.1" | sudo tee /etc/resolver/ts.net

/etc/resolver/<domain>은 macOS 시스템 resolver(getaddrinfo)에서만 적용된다. nslookup/dig은 이 설정을 우회하므로 검증할 때 부적합. dscacheutil -q host -a name <fqdn> 또는 실제 애플리케이션(nc, ssh, ping) 사용.

short name(ssh kaffa@incus-kr1)도 풀리려면 search domain이 라우터 tailnet과 일치해야 한다. macOS Tailscale 클라이언트가 stopped여도 이전 가입했던 tailnet의 search domain(taila*****.ts.net)이 잔재로 남아 있을 수 있다:

sudo networksetup -setsearchdomains Wi-Fi otter-buri.ts.net

이 설정은 macOS 차원에서 고정되어 다른 Wi-Fi에 옮겨도 유지된다(다른 네트워크의 DHCP search domain은 무시됨).

운영 주의

Beryl LAN을 벗어나면 ts.net 풀이가 timeout (Mac이 192.168.8.1을 못 찾음). 외부 네트워크에선 Mac Tailscale을 다시 켜야 한다 — /etc/resolver/ts.net은 라우터 도달 가능성을 전제로 함
펌웨어 업그레이드 시 "Keep Settings" ON 필수. 위 fw3 masq, dnsmasq split-forward 모두 UCI 설정이라 keep settings로 보존됨
더블 NAT 환경에서 NAT punching이 일부 peer만 성공할 수 있다(예: 한국 인프라끼리 punch 실패, 일본 인프라는 direct 성공). 나머지는 DERP relay로 자동 폴백되므로 통신 자체엔 문제 없음 — 단, 위 SNAT 설정이 있어야 LAN 트래픽이 정상 흐름
LuCI(:8080)와 GL.iNet UI(:80/443)가 동시 운영. 펌웨어 업그레이드는 GL.iNet UI의 Online Upgrade가 가장 단순

4.8 KiB Raw Blame History