メインコンテンツへスキップ
見出し画像

GuestからNASを見せない|firewall zoneを部屋分けで理解する【OpenWrt集中連載016】

    ゲストWi-Fiはインターネットへ出したい。でも、NAS、プリンター、カメラ、LuCIは見せたくない。

    IoT機器はクラウドへ接続させたい。でも、社内PCへ自由に入らせたくない。VPNは便利でも、接続した人へLAN全体を渡す必要はありません。

    この境界を作るのが、OpenWrtの firewall zone です。難しい名前ですが、最初は部屋と通路で考えると整理できます。

    今回使っているOpenWrtルーターはこちらです。


    連載目次: LN6001-JPで始めるOpenWrtルーター実践ガイド

    zoneは「部屋」、forwardingは「通路」

    zoneは、一つ以上のネットワークインターフェースを同じセキュリティ境界へまとめます。

    LAN・Guest・IoT・VPN・WANを部屋として分ける

    たとえば、小さなオフィスなら次のように分けられます。

    • lan または staff: 管理PC、NAS、プリンター

    • guest: 来訪者のスマートフォン

    • iot または device: カメラ、センサー、設備機器

    • vpn: 外出先から接続する端末

    • wan: インターネット回線側

    部屋を作っただけでは、部屋どうしを移動できません。guest → wan のようなzone forwardingを追加すると、その方向の通路ができます。逆向きの wan → guest が自動で開くわけではありません。

    Input・Output・Forwardの向きを間違えない

    三つの言葉は、誰に向かう通信かで読みます。

    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の通信方針

    lan → wan は明示的に許可されます。WAN側は通常、InputとForwardが拒否、Outputが許可です。さらにWAN zoneでは、IPv4のNATに関係するmasqueradingが使われます。

    既存の lan と wan をいきなり作り直さず、この基準へGuest、IoT、VPNを足します。

    Guest zoneの基本形

    ゲストに必要なのは、インターネット接続と、ルーターから受け取るDHCP・DNSです。NASや管理画面への自由なアクセスではありません。

    Guest zoneの基本ポリシーと通路

    基本方針は次の通りです。

    • 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アドレスを受け取る通信と、ルーターへ名前解決を依頼する通信も止まります。

    Guestで許可するDHCPとDNSの二つの例外

    そのため、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ネットワークを安全に追加する順番

    Guest用network・DHCP・SSIDを対応させ、zoneとDHCP/DNSの例外を作ります。具体的な入力は007のゲストWi-Fi手順で確認してください。有線の管理経路を残したまま適用し、次の許可・拒否テストへ進みます。

    「使える」と「遮断できる」を両方試す

    インターネットが開いただけでは、分離が成功した証拠になりません。

    Guest zoneで確認する許可と拒否のテスト

    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と異なります。

    IoT・Device zoneで先に決める通信要件

    カメラはクラウドへ出る必要があるか。社内の録画サーバーへ送るか。スマートフォンから同一LANで初期設定するか。mDNSやブロードキャスト探索が必要か。製品ごとに違います。

    最初から iot → lan を丸ごと許可せず、次のどちらかを検討します。

    • 信頼するStaff側からIoT機器へ管理通信を始める

    • IoTから必要な宛先・ポートだけをTraffic Rulesで許可する

    クラウド不要の機器なら、IoTからWANへの通路を作らない選択もあります。

    VPNは「LANの仲間」へ自動昇格させない

    VPNへ接続できることと、LAN全体へ入れることは別です。

    VPNから許可する管理対象を限定する

    管理目的なら、VPN zoneから次のように絞ります。

    • NASの管理画面だけ

    • 特定サーバーのSSHだけ

    • LuCIは管理端末または管理用VPNだけ

    • プリンターは必要な利用者だけ

    WireGuardのAllowedIPsは経路と暗号化対象を決める仕組みで、アクセス権限の代わりにはなりません。Tailscaleも端末認証に加え、ルート承認やアクセス制御を確認します。

    便利だからという理由でVPNインターフェースを lan zoneへまとめると、想定以上の範囲へ届く場合があります。VPN専用zoneを作り、必要な通路だけを許可するほうが説明しやすくなります。

    Traffic Rulesは例外を小さく作る

    Traffic Rulesは、「誰が、どこへ、何の通信をしてよいか」を狭く指定する場所です。

    Traffic Rulesを送信元・宛先・サービス・方向で定義する

    例外を作る前に、四つを言葉で書きます。

    1. 送信元zoneまたは送信元端末

    2. 宛先zoneまたは宛先IP

    3. プロトコルとポート

    4. 許可する方向

    たとえば「Staffから録画サーバーのHTTPSへ許可」と、宛先と用途を特定します。

    不要になった例外は削除します。ルール名には用途を入れ、半年後に見ても理由が分かるようにします。

    うまくいかない時は症状から戻る

    firewall zone設定で起きやすい症状と確認場所

    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名だけではありません。

    • zoneに属するネットワークとSSID

    • Input / Output / Forwardの方針

    • 許可したzone forwarding

    • Traffic Rulesの目的と管理者

    • 確認した許可・拒否テスト

    • 変更日、実施者、戻し方

    「GuestはLANへ入れない」のように、人が読める文章でも残します。設定ファイルだけより、意図を引き継ぎやすくなります。

    次に読むなら

    参考情報

     
     
    外資系テックの仕事と、ネットワーク・AI・動画制作を実際に試す人。日本の仕事を少し便利にする方法を書いています。Linksys / OpenWrt / IPoE / Apple / YouTube tools. 個人の発信です。

    あなたへのおすすめ