
GuestからNASを見せない|firewall zoneを部屋分けで理解する【OpenWrt集中連載016】
ゲストWi-Fiはインターネットへ出したい。でも、NAS、プリンター、カメラ、LuCIは見せたくない。
IoT機器はクラウドへ接続させたい。でも、社内PCへ自由に入らせたくない。VPNは便利でも、接続した人へLAN全体を渡す必要はありません。
この境界を作るのが、OpenWrtの firewall zone です。難しい名前ですが、最初は部屋と通路で考えると整理できます。
今回使っているOpenWrtルーターはこちらです。
zoneは「部屋」、forwardingは「通路」
zoneは、一つ以上のネットワークインターフェースを同じセキュリティ境界へまとめます。

たとえば、小さなオフィスなら次のように分けられます。
lan または staff: 管理PC、NAS、プリンター
guest: 来訪者のスマートフォン
iot または device: カメラ、センサー、設備機器
vpn: 外出先から接続する端末
wan: インターネット回線側
部屋を作っただけでは、部屋どうしを移動できません。guest → wan のようなzone forwardingを追加すると、その方向の通路ができます。逆向きの wan → guest が自動で開くわけではありません。
Input・Output・Forwardの向きを間違えない
三つの言葉は、誰に向かう通信かで読みます。

Input
そのzoneからルーター自身へ届く通信です。LuCI、SSH、ルーター上のDNSやDHCPが対象になります。
Guest zoneのInputを REJECT にすると、ゲスト端末からルーター自身への通信は原則拒否されます。そのため、ルーターのDHCPとDNSを使わせる場合は、必要な通信だけTraffic Rulesで許可します。
Output
ルーター自身が、そのzone側へ送る通信です。一般的なLAN・Guest・IoT zoneでは ACCEPT がよく使われます。
Forward
ルーターを通過する通信です。正確には、そのzoneに含まれるインターフェース間を通過する通信の既定方針です。zone間の移動は、明示したzone forwardingやTraffic Rulesでも制御されます。
「ForwardをACCEPTにすればGuestからLANへ行ける」という単純な理解は危険です。zoneの既定方針、zone forwarding、Traffic Rulesを一緒に見ます。
標準のLANとWANを基準にする
一般的なルーター構成では、信頼するLANからWANへ出られ、WANからLANへ新規接続を始めることは拒否されます。

lan → wan は明示的に許可されます。WAN側は通常、InputとForwardが拒否、Outputが許可です。さらにWAN zoneでは、IPv4のNATに関係するmasqueradingが使われます。
既存の lan と wan をいきなり作り直さず、この基準へGuest、IoT、VPNを足します。
Guest zoneの基本形
ゲストに必要なのは、インターネット接続と、ルーターから受け取るDHCP・DNSです。NASや管理画面への自由なアクセスではありません。

基本方針は次の通りです。
Input: REJECT
Output: ACCEPT
Forward: REJECT
zone forwarding: guest → wan のみ
Traffic Rules: GuestからルーターのDHCPとDNSだけ許可
guest → lan: 作らない
OpenWrt公式のGuest Wi-Fi手順も、この考え方を基本にしています。
DHCPとDNSは「ルーター自身への例外」
Inputを拒否したGuest zoneでは、端末がルーターからIPアドレスを受け取る通信と、ルーターへ名前解決を依頼する通信も止まります。

そのため、Traffic Rulesで次を許可します。
DHCP: GuestからルーターのUDP 67番
DNS: GuestからルーターのTCP / UDP 53番
DNSはUDPだけでなくTCPも使う場合があります。53番はTCPとUDPの両方を許可します。
IPv6をGuestで使う場合は、DHCPv6やICMPv6を含め、IPv6向けの設計も必要です。IPv4用の二つのルールだけでIPv6まで完成したとは考えません。
LuCIでは一度に全部変えない
ここでのLuCIと実ルール確認は、LN6001-JPのメーカー提供のOpenWrtベースのOS(ver. 1.2.0.15)が前提です。upstream OpenWrt 22.03以降は標準のFirewallがnftablesを使うfirewall4へ移っています。同じzone設計でも、現在のLN6001-JPへ新しい記事の nft コマンドをそのまま当てはめないでください。ファームウェアの区別は003の解説にまとめています。
設定前に、現在の状態と戻し方を残します。
uci show firewall
uci show network
uci show wireless
uci show dhcp
iptables-save
ip6tables-save

Guest用network・DHCP・SSIDを対応させ、zoneとDHCP/DNSの例外を作ります。具体的な入力は007のゲストWi-Fi手順で確認してください。有線の管理経路を残したまま適用し、次の許可・拒否テストへ進みます。
「使える」と「遮断できる」を両方試す
インターネットが開いただけでは、分離が成功した証拠になりません。

Guest端末で、次を確認します。
Guest SSIDへ接続できる
Guest用のIPアドレスを受け取れる
DNSで名前解決できる
Webサイトを開ける
LANのNASやプリンターへ到達できない
LuCIとSSHへ到達できない
Guest端末どうしも分離する設計なら、相互通信できない
最後の端末間分離は、firewall zoneだけでなく、無線側のClient Isolationも関係します。同じSSID・同じL2内の通信は、ルーターのzone間forwardingを通らない場合があるためです。
拒否の確認は、NASが停止しているだけでも「成功」に見えます。先に管理用LANから対象サービスが使えることを確認し、次にGuestから同じ宛先・同じサービスへ接続します。IPv4とIPv6を分け、既存の画面を眺めるだけでなく新しく接続し直して試します。
Guestから届いてしまった時は、そのSSIDの利用をいったん止め、有線の管理経路を保ったまま直前の変更を戻します。業務LANまで広く許可して直すと、分離という目的が失われます。
IoTはGuestと同じとは限らない
IoT機器も信頼度は低めですが、運用上の要件がGuestと異なります。

カメラはクラウドへ出る必要があるか。社内の録画サーバーへ送るか。スマートフォンから同一LANで初期設定するか。mDNSやブロードキャスト探索が必要か。製品ごとに違います。
最初から iot → lan を丸ごと許可せず、次のどちらかを検討します。
信頼するStaff側からIoT機器へ管理通信を始める
IoTから必要な宛先・ポートだけをTraffic Rulesで許可する
クラウド不要の機器なら、IoTからWANへの通路を作らない選択もあります。
VPNは「LANの仲間」へ自動昇格させない
VPNへ接続できることと、LAN全体へ入れることは別です。

管理目的なら、VPN zoneから次のように絞ります。
NASの管理画面だけ
特定サーバーのSSHだけ
LuCIは管理端末または管理用VPNだけ
プリンターは必要な利用者だけ
WireGuardのAllowedIPsは経路と暗号化対象を決める仕組みで、アクセス権限の代わりにはなりません。Tailscaleも端末認証に加え、ルート承認やアクセス制御を確認します。
便利だからという理由でVPNインターフェースを lan zoneへまとめると、想定以上の範囲へ届く場合があります。VPN専用zoneを作り、必要な通路だけを許可するほうが説明しやすくなります。
Traffic Rulesは例外を小さく作る
Traffic Rulesは、「誰が、どこへ、何の通信をしてよいか」を狭く指定する場所です。

例外を作る前に、四つを言葉で書きます。
送信元zoneまたは送信元端末
宛先zoneまたは宛先IP
プロトコルとポート
許可する方向
たとえば「Staffから録画サーバーのHTTPSへ許可」と、宛先と用途を特定します。
不要になった例外は削除します。ルール名には用途を入れ、半年後に見ても理由が分かるようにします。
うまくいかない時は症状から戻る

Guest端末がIPを取れない
Guestインターフェース、DHCPサーバー、SSIDのnetwork割り当て、DHCP許可ルールを確認します。端末が 169.254.x.x なら、DHCP失敗の可能性があります。
IPは取れるがWebが開かない
DNS許可、guest → wan、WAN自体の接続を確認します。IPアドレス宛ての通信と名前解決を分けます。
GuestからNASが見える
Guest SSIDが誤って lan networkへ割り当てられていないか、guest → lan のforwardingや広すぎるTraffic Ruleがないかを確認します。
GuestからLuCIが開く
Guest zoneのInput、LuCI・SSH向けTraffic Rules、管理サービスのlisten設定を確認します。
Save & Apply後に管理画面へ入れない
有線LANから現在の管理IPへ接続します。直前に変更したinterfaceとzoneの割り当てを見直し、保存したバックアップから戻します。
運用メモを一枚残す

記録するのは、zone名だけではありません。
zoneに属するネットワークとSSID
Input / Output / Forwardの方針
許可したzone forwarding
Traffic Rulesの目的と管理者
確認した許可・拒否テスト
変更日、実施者、戻し方
「GuestはLANへ入れない」のように、人が読める文章でも残します。設定ファイルだけより、意図を引き継ぎやすくなります。
次に読むなら
Guestネットワークを作る: ゲストWi-FiはSSIDだけでは完成しない|家庭内LANから分離する
IoTを分ける: IoT用ネットワークを追加する
VPNを安全に使う: ポート開放の前にVPNを考える|WireGuardとTailscaleで外から安全に入る