---
title: Beryl AX (GL-MT3000) 휴대용 라우터
updated: 2026-05-01
tags: [openwrt, glinet, tailscale, router, portable]
---

## 호스트 정보

| 항목 | 값 |
|------|-----|
| 모델 | 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)만 응답 가능.

**영구 적용**:
```sh
uci set firewall.tailscale0.masq='1'
uci add_list firewall.tailscale0.masq_src='192.168.8.0/24'
uci commit firewall
fw3 reload
```

**검증**:
```sh
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를 안 건드리고 가장 안전.

**영구 적용**:
```sh
uci add_list dhcp.@dnsmasq[0].server='/ts.net/100.100.100.100'
uci commit dhcp
/etc/init.d/dnsmasq restart
```

**검증**:
```sh
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 도메인만 라우터로 보내려면:

```sh
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`)이 잔재로 남아 있을 수 있다:

```sh
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가 가장 단순

## 관련 문서

- [[infra-hosts]] — 서버 목록
- [[openwrt]] — 서울 OpenWrt 라우터 (별도 거점, Beryl과 다름)