CRS304でローカル10GbEと段階的な外部通信制御を両立する
MikroTik CRS304をRouterOS兼10GbEスイッチとして使い、VLAN分離・allowlistベースのegress制御・Prometheus/Loki監視を一台で実現する設計と構成。
はじめに
CRS304 を RouterOS で触り始めたとき、最初に固めたのは VLAN 分離と Firewall の基本方針でした。そこまでは前のメモで整理できていたのですが、実際に日常運用の形を詰めていくと、Linux をどう外に出すかよりも、どうやって普段は外に出さないかのほうが重要だと分かってきました。しかも今回は、単に Linux の egress を絞るだけではなく、Mac と Linux の間では 10GbE のローカル転送を活かしたいという要求もありました。
そこで最終的には、CRS304 を「VDSL 環境ではルーター兼スイッチ」として使い、Port2 と Port3 をローカル高速転送のための有線ポートにしつつ、Wi-Fi AP 側を家庭内のインターネット出口として分離する構成に整理しました。Linux の新規外部通信は allowlist ベース、Mac は緩め、ISP 側からの inbound は全面 drop、監視は Prometheus と Loki で押さえる、という形です。
この記事では、最初に作った VLAN 分離と RouterOS のベース設計を押さえたうえで、その後に固めた物理構成、性能の見立て、運用ポリシー、監視の置き方まで含めてまとめます。狙いは一貫していて、普段はローカル中心、必要なときだけ最小限に外へ出すことです。
背景と目的
常用端末、Wi-Fi クライアント、IoT、検証用 Linux を全部同じ感覚で扱うと、どこまでがローカルでどこからが外向きなのかが曖昧になります。特に Linux 側は、普段はローカル開発とファイル転送に閉じていたい一方で、更新時だけ apt、pypi、ghcr.io のような正規配布元には出したい、という濃淡がありました。
同時に、Mac と Linux の間のローカル転送は 10GbE で維持したかったので、単純に「Linux を Wi-Fi だけに寄せる」という構成にはしたくありませんでした。ほしかった条件は次の通りです。
- Mac と Linux の間ではローカル高速転送を維持する
- Linux は通常時に外部通信できないか、極小の allowlist に限定する
- Mac は日常利用の自由度を落としすぎない
- IoT / mobile は有線ローカル系から切り離す
- ISP 側からの入力は例外なく遮断する
- ログとメトリクスを後から追えるようにする
この条件を満たすために、RouterOS 側では VLAN 分離と stateful firewall を組み、そのうえで Linux 専用の allowlist / denylist 制御、物理ポートの役割固定、将来の FTTH 移行まで含めた使い回し方を考えました。
全体設計(要約)
最終的に整理したポートの役割は次の通りです。
Port1 = WANPort2 = Mac または有線クライアント系Port3 = LinuxPort4 = Wi-Fi AP trunkPort5 = Console / 管理
VLAN の考え方はベース設計のまま維持しています。
VLAN10 = Wired-LANVLAN20 = Wi-Fi TrustedVLAN30 = Wi-Fi IoT
ここに新しいメモの運用方針を重ねると、「Port2 / Port3 の有線はローカル主体」「Wi-Fi AP は家庭内インターネット出口」「Linux の new 接続だけ allowlist で制御」「WAN からの input は全 drop」「監視は SNMP exporter と Syslog/Loki」という整理になります。
1) アドレス設計(例)
ベースのアドレス設計は次の通りです。
10.10.10.0/24を有線 LAN10.20.20.0/24を Trusted Wi-Fi10.30.30.0/24を IoT Wi-Fi- WAN は DHCP クライアント
今回のメモでは、これとは別に運用イメージとして 1.10 から 1.13 の役割も置いています。
| デバイス | IP | 用途 |
|---|---|---|
| ONU | ISP 割当 (WAN 側) | VDSL 回線終端 |
| CRS304 | 1.10 | ルーター / NAT / DHCP サーバ |
| Wi-Fi AP | 1.11 | 無線クライアント配下 |
| Mac | 1.12 | Linux との有線やり取り専用 |
| Linux | 1.13 | Mac とのローカル転送主体、外向きは個別制御 |
この二つの書き方は矛盾というより粒度の違いで、RouterOS の実装レベルでは 10.x のセグメント設計、運用メモとしては 1.10 から 1.13 の役割整理、という見方で扱っています。
2) RouterOS v7 構成スクリプト(たたき台)
まずはベースになる RouterOS v7 の構成です。ブリッジ、VLAN、DHCP、DNS、NAT、Firewall を一通りここで定義しています。
# ========== インタフェースとブリッジ ==========
/interface bridge add name=br-core vlan-filtering=yes protocol-mode=none
# 物理ポート割当(例)
# ether1=Port1(WAN), sfp-sfpplus1=Port2(Mac), sfp-sfpplus2=Port3(Linux),
# sfp-sfpplus3=Port4(AP), sfp-sfpplus4=Port5(Console)
# 実機のif名に合わせて修正
/interface bridge port
add bridge=br-core interface=sfp-sfpplus1 pvid=10 # Mac: access VLAN10
add bridge=br-core interface=sfp-sfpplus2 pvid=10 # Linux: access VLAN10
add bridge=br-core interface=sfp-sfpplus3 # AP: trunk (tagged)
add bridge=br-core interface=sfp-sfpplus4 pvid=10 # Console: access VLAN10(管理をLANから)
# WAN はブリッジに入れない(ルーターポートとして独立)
# ether1 は WAN 専用
# ========== VLAN インタフェース ==========
/interface vlan
add name=vlan10-LAN interface=br-core vlan-id=10
add name=vlan20-TRUST interface=br-core vlan-id=20
add name=vlan30-IOT interface=br-core vlan-id=30
# ========== VLAN タグ付与設定 ==========
/interface bridge vlan
# VLAN10: access on Port2/3/5 (untagged), tagged on bridge-cpu
add bridge=br-core vlan-ids=10 tagged=br-core untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus4
# VLAN20: tagged on AP trunk + bridge-cpu
add bridge=br-core vlan-ids=20 tagged=br-core,sfp-sfpplus3
# VLAN30: tagged on AP trunk + bridge-cpu
add bridge=br-core vlan-ids=30 tagged=br-core,sfp-sfpplus3
# ========== IP アドレス ==========
/ip address
add address=10.10.10.1/24 interface=vlan10-LAN comment="LAN gw"
add address=10.20.20.1/24 interface=vlan20-TRUST comment="Trusted gw"
add address=10.30.30.1/24 interface=vlan30-IOT comment="IoT gw"
# WAN は DHCP
/ip dhcp-client add interface=ether1 use-peer-dns=no use-peer-ntp=yes add-default-route=yes
# ========== DHCP サーバ(Wi-Fi用。LANは固定でも可) ==========
/ip pool add name=pool-trust ranges=10.20.20.100-10.20.20.199
/ip pool add name=pool-iot ranges=10.30.30.100-10.30.30.199
/ip dhcp-server add name=dhcp-trust interface=vlan20-TRUST address-pool=pool-trust lease-time=12h
/ip dhcp-server add name=dhcp-iot interface=vlan30-IOT address-pool=pool-iot lease-time=12h
/ip dhcp-server network
add address=10.20.20.0/24 gateway=10.20.20.1 dns-server=10.20.20.1
add address=10.30.30.0/24 gateway=10.30.30.1 dns-server=10.30.30.1
# ========== DNS(ルータを唯一のDNSに) ==========
/ip dns set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes use-doh-server="" verify-doh-cert=no
# ========== アドレスリスト(Port3-Linuxの許可先) ==========
# 直接IPで許可したい先
/ip firewall address-list
add list=allowlist-Linux comment="例: Gitホスト" address=203.0.113.10
add list=allowlist-Linux comment="例: R2/Cloud" address=198.51.100.20
# もしドメイン許可が必要なら(動的解決):
# RouterOS v7は /ip/firewall/address-list add address=example.com でFQDN可(DNS依存)
add list=allowlist-Linux address=github.com
add list=allowlist-Linux address=registry-1.docker.io
add list=allowlist-Linux address=ghcr.io
# ========== NAT ==========
# Trusted/IOT → WAN のみマスカレード(LAN→WANは不可にするので不要でも良いが保険でON)
/ip firewall nat
add chain=srcnat src-address=10.20.20.0/24 out-interface=ether1 action=masquerade comment="Trusted -> WAN"
add chain=srcnat src-address=10.30.30.0/24 out-interface=ether1 action=masquerade comment="IoT -> WAN"
# VLAN10(LAN) はインターネット禁止のため NAT しない(誤設定時の外出し防止)
# ========== Firewall 基本ポリシー ==========
# 1) 既定:全部閉じる(最後に drop)
# 2) state: established, related は許可。invalidはdrop
# 3) WAN→ルータ input は既定 drop(必要最小限のみ許可)
# 4) forward はVLAN間/対WANをポリシーベースで制御
/ip firewall filter
# --- hygiene
add chain=input connection-state=invalid action=drop comment="DROP invalid"
add chain=forward connection-state=invalid action=drop comment="DROP invalid"
add chain=input connection-state=established,related action=accept
add chain=forward connection-state=established,related action=accept
# --- WAN側からの input は all drop(DHCPクライアントの更新等は別経路)
add chain=input in-interface=ether1 action=drop comment="DROP all from ISP(WAN)"
# --- ルータ管理:VLAN10 からのみ許可(Winbox/SSH/HTTPS 等)
add chain=input in-interface=vlan10-LAN src-address=10.10.10.0/24 action=accept comment="Mgmt from LAN"
# 必要なら VLAN20 からも限定許可
# add chain=input in-interface=vlan20-TRUST src-address=10.20.20.0/24 action=accept
# --- DNS サービス(全VLANからルータのDNSを使わせる)
add chain=input protocol=udp dst-port=53 in-interface-list=LAN action=accept comment="DNS UDP"
add chain=input protocol=tcp dst-port=53 in-interface-list=LAN action=accept comment="DNS TCP"
# インターフェイスリストでLAN系を包括
/interface list add name=LAN
/interface list member
add list=LAN interface=vlan10-LAN
add list=LAN interface=vlan20-TRUST
add list=LAN interface=vlan30-IOT
# --- VLAN間ポリシー ---
# 既定:相互隔離(必要な穴だけ下に書く)
# 1) IoT は他VLANへのアクセス禁止(DNSは input で受けるためOK)
add chain=forward in-interface=vlan30-IOT out-interface=!ether1 action=drop comment="Isolate IoT to others"
# 2) Trusted -> LAN を既定禁止(必要なら個別許可)
add chain=forward in-interface=vlan20-TRUST out-interface=vlan10-LAN action=drop comment="Block Trusted->LAN by default"
# 3) LAN(有線) 同士は許可(Mac/Linus/Console間のローカル通信)
add chain=forward in-interface=vlan10-LAN out-interface=vlan10-LAN action=accept comment="Allow LAN intra"
# --- WAN への出口ポリシー ---
# VLAN10(LAN) は WAN 禁止
add chain=forward src-address=10.10.10.0/24 out-interface=ether1 action=drop comment="Block LAN->WAN"
# VLAN20/30 は WAN 許可(上の established でOK。念のため明示)
add chain=forward src-address=10.20.20.0/24 out-interface=ether1 action=accept comment="Trusted->WAN"
add chain=forward src-address=10.30.30.0/24 out-interface=ether1 action=accept comment="IoT->WAN"
# --- ポート別要件(Port2/3) ---
# Port2=Mac(LAN内 NEW 制限なし)→ 既に VLAN10 intra を許可済み。WAN は上で禁止。
# Port3=Linux(NEW は allowlist のみ + ローカル)
# 1) Linux のIPまたはMACで識別(例はIP固定: 10.10.10.13)
/ip firewall address-list add list=linux-host address=10.10.10.13
# 2) Linux からの NEW を既定 drop(まずブロックしてから穴あけ)
add chain=forward src-address-list=linux-host connection-state=new action=drop comment="Linux NEW default drop"
# 3) 例外許可:LAN内(Mac/Console/ルータ)へは NEW 許可
add chain=forward src-address-list=linux-host dst-address=10.10.10.0/24 connection-state=new action=accept comment="Linux NEW to LAN allowed"
# 4) 例外許可:allowlist (FQDN/IP) 宛は NEW 許可
add chain=forward src-address-list=linux-host dst-address-list=allowlist-Linux connection-state=new action=accept comment="Linux NEW to allowlist allowed"
# --- 既定 DROP(最後尾) ---
add chain=input action=drop comment="Default drop input"
add chain=forward action=drop comment="Default drop forward"
このベースだけでも閉じた設計として成立していましたが、新しいメモで整理したのは「この構成をどう日常運用に落とし込むか」です。
論理構成(ゾーン分離)
追加した論理構成では、Linux の外向き用途を二つのゾーンに分けます。
VLAN10 (192.168.10.0/24)は Update 専用VLAN15 (192.168.15.0/24)は長時間学習や一時的なネット依存タスク専用
さらに、通信許可の考え方も分けています。
dev-allowはapt,pip,npm,docker,github,googleなど更新寄りtemporary-allowはHuggingFace,Kaggle, container registry など学習寄り
ただ、今回のメモでより現実的だったのは、論理設計だけでなく物理構成とルータ性能を同時に見ることでした。ルールを細かく書けても、ローカル転送や将来の回線切り替えまで含めて無理がある構成だと、結局運用で崩れます。
構成イメージ
物理構成のイメージは次の通りです。
ONU (VDSL) → CRS304 (Router)
|
|-- Port1 → WAN
|-- Port2 → Mac (1.12, 基本はWi-Fi利用、LANはローカル専用)
|-- Port3 → Linuxサーバ (1.13, 有線はローカル専用)
|-- Port4 → WiFi AP
|-- Port5 → Console
この形にしておくと、CRS304 は次の三役を同時にこなせます。
- ONU に直結するルーター
- Mac と Linux のローカル高速転送を担う 10GbE スイッチ
- 家庭内 Wi-Fi とローカル有線を束ねる中継点
Port2 と Port3 は L2 スイッチングで直結できるので、ファイル転送やローカル開発データのやり取りでは WAN を経由しません。ローカル転送は有線のまま高速に回し、外向き通信だけを RouterOS のポリシーで絞る、という役割分担にできます。
IP・ルーティングの整理
運用メモとしては次の整理がしっくりきました。
| デバイス | IP | 用途 |
|---|---|---|
| ONU | ISP 割当 (WAN 側) | VDSL 回線終端 |
| CRS304 (Router) | 1.10 | ルーター / NAT / DHCP サーバ |
| Wi-Fi AP | 1.11 | 無線クライアントのゲートウェイ配下 |
| Mac | 1.12 | Linux とのローカルやり取り専用 |
| Linux | 1.13 | ローカル転送主体、外向きは限定許可 |
Linux と Mac はローカル転送、Linux / Mac から Wi-Fi AP 経由で CRS304 から ONU へはインターネット側、という分離が明確です。これにより「有線はローカル専用、外へ出さない」という制御を RouterOS に任せやすくなります。
CRS304 の役割
今回のメモで改めて整理できたのは、CRS304 を単なる暫定ルーターではなく「いま必要な要件を一台で満たす装置」として見ることでした。
ルーターとして
VDSL 回線の終端である ONU に直結し、NAT / DHCP / Firewall を受け持ちます。現状の回線速度が 100Mbps 級であれば、RouterOS のルーティング性能でも十分回ります。
スイッチとして
Port2 と Port3 の間は L2 スイッチングで処理できるので、ローカルファイル転送では 10GbE を活かせます。ここをわざわざ別スイッチに切り出さず、同じ CRS304 の中で処理できるのが実用的でした。
ハブ的な統合点として
Wi-Fi AP を Port4 にぶら下げれば、家庭内全体のインターネット系クライアントを別セグメントで収容できます。つまり、ローカル高速転送・無線クライアント・外向き制御を一台でまとめられます。
運用ルール
この設計でいちばん効いているのは、設定だけでなく物理運用を制御条件に入れた点です。
- 普段は Linux
NIC3を未接続にする - 更新するときだけ
ether2に挿す - 学習や一時取得のときだけ
ether3に挿す - Linux 側でも対応する IP と GW を切り替える
今回のメモでは、この思想をさらに単純化して「Mac と Linux の有線はまずローカル専用」「外部アクセスは Wi-Fi セグメントや allowlist 制御のある経路で扱う」と整理しました。つまり、Linux 側だけ設定した、ケーブルだけ挿した、RouterOS 側の allowlist だけ入れた、のどれか一つでは通信できない構成を維持します。
3) Wi-Fi AP 側の設定(概念)
AP 側は ether4 を trunk として使い、VLAN20 と VLAN30 をタグ付きで上げる前提です。
- SSID1 を Trusted 側に割り当てる
- SSID2 を IoT 側に割り当てる
これで Wi-Fi クライアントは有線 LAN と明確に切り分けられます。LAN を厳しく閉じつつ、普段のクライアント用途だけは Wi-Fi 側でインターネットを使える構成です。
4) 追加のおすすめ強化
ベース設計の段階でも、今後足したい強化ポイントがいくつかありました。
- AdGuard Home を前段に置いて GUI で allowlist / denylist を管理する
- IoT と Trusted の間で mDNS 中継が必要なら専用プロキシを入れる
- log-prefix 付き drop ルールで不足している許可先を洗い出す
RouterOS 単体でもかなり制御できますが、FQDN ベースの管理や DNS の見え方まで含めると、前段の補助ツールがあるほうが運用しやすいと感じています。
5) Validation Checklist
以前のチェック項目はそのまま有効です。
- Linux が通常時に WAN へ出られない
dev-allow/temporary-allowを分けて差分管理できる- Wi-Fi Trusted と IoT が分離されている
- VLAN 間は明示ルール以外で通らない
- ルータ自身の管理面が WAN から露出しない
ここに今回のメモで追加された観点を重ねます。
- Port2 / Port3 のローカル転送が WAN を経由せずに成立する
- Mac は日常運用で窮屈にならない
- Linux はローカル中心のまま、必要時だけ段階的に外へ出せる
- 監視で drop / login failure / config change を追える
この構成のメリット
今の VDSL 回線に対して過不足がない
ルーティング性能の絶対値だけで見れば CRS304 は本格ルーターではありませんが、現状が 100Mbps 級の VDSL であれば十分です。むしろ、ローカル 10GbE 転送を持ちながらルータ機能も一台でこなせる点のほうが効いています。
将来の FTTH / 1G / 10G 移行でも投資が無駄にならない
将来、光 1G / 10G へ切り替えるときは、CRS304 を SwOS モードのスイッチ専用に回し、CCR, RB5009, L009 のような本格ルーターを前段に追加すればいい、という見通しが立っています。いまはルーター兼スイッチ、将来は 10GbE スイッチ専用という二段活用ができます。
消費電力が低く、常設しやすい
消費電力が 15 から 21W 程度に収まり、UPS や雷対策を含めた常設運用と相性がいい点も実用的でした。
Switching results(スイッチ性能)
今回のメモでは、L2 スイッチング性能の目安も整理しました。
- Non blocking Layer 2 throughput / capacity は約
39,480 Mbpsから40,000 Mbps - 64 バイトパケット時でも約
30から40 Gbps
ローカル転送を主目的にするなら、この部分は十分に余裕があります。Mac と Linux の間の大容量ファイルコピーや、ローカルデータセットの受け渡しに向いた数値です。
Ethernet test results(ルーター/フィルタ性能)
RouterOS で CPU が関わる経路については、次の整理にしました。
| Mode | 条件 | 実測 |
|---|---|---|
| Bridging (none, fast path) | フィルタなし、ブリッジ高速処理 | ~2.0 Gbps |
| Bridging (25 bridge filter rules) | ブリッジ + 25 個のフィルタルール | ~1.0 Gbps |
| Routing (none, fast path) | ルーティングのみ、フィルタなし | ~2.0 Gbps |
| Routing (25 simple queues) | 帯域制御ルール 25 個 | ~1.0 Gbps |
| Routing (25 ip filter rules) | IP フィルタ 25 個 | ~0.5 - 1.5 Gbps |
素のルーティング / ブリッジングなら 2Gbps 程度、フィルタやキューを増やすと 0.5 から 1.0Gbps 台まで落ちる、という見方です。VDSL 前提ではボトルネックになりませんが、将来 FTTH に移ったときは「CRS304 をどこまで RouterOS ルータとして残すか」の判断材料になります。
ネットワーク構成 & 運用まとめ
ここまでを一行でまとめると、「CRS304 をいまは RouterOS ルーター兼 10GbE ローカルスイッチとして使い、ローカル有線・家庭内 Wi-Fi・Linux の外向き通信を役割分離して運用する」という構成です。
物理構成
VDSL → CRS304 (RouterOS)
| (All RJ45)
|-- Port1 → WAN
|-- Port2 → Mac (1.12, 基本Wi-Fi, 有線=ローカル専用)
|-- Port3 → Linuxサーバ (1.13, 有線=ローカル専用)
|-- Port4 → Wi-Fi AP (1.11, IoT/Mobile用セグメント)
|-- Port5 → Console
- CRS304: ルーター兼スイッチ
- Mac と Linux: 10GbE でローカル高速転送
- Wi-Fi AP: インターネット出口、IoT / Mobile は別セグメント
Firewall / フィルターポリシー
基本方針
- ISP 側からの inbound は全て drop
- outbound はドメイン allowlist ベース
- Mac は制限なし
- Linux は必要な権威あるドメインのみ許可
established,relatedは allow
実装イメージ
Linux (Port3) では、outbound new を allowlist ドメインだけに絞ります。例として apt, pypi, ghcr.io のような正規のアップデート元を通し、それ以外はデフォルトで落とします。Mac (Port2) は日常利用の自由度を優先し、outbound new に制限をかけません。全ポート共通では inbound は all drop、RouterOS 管理サービスは管理用 IP のみ、SSH 鍵認証を前提にし、drop ルールには log-prefix を付けて監査できるようにします。
メトリクス & ログ監視
監視は「機器の健康状態を見る経路」と「挙動異常を検出する経路」を分けています。
SNMP exporter (Prometheus)
SNMP exporter では CPU、メモリ、インターフェイス帯域、温度、uptime を取ります。Grafana では CPU 高負荷が継続していないか、帯域使用率の推移が不自然でないかを見る想定です。ハードウェアの健診としてはこれで十分です。
Syslog から Loki
Loki 側では DROP ログ、SSH ログイン失敗、設定変更、DNS 解決の異常を追います。Grafana では次のようなクエリを想定しています。
count_over_time({job="routeros"} |= "DROP" [1m])
count_over_time({job="routeros"} |= "login failure" [5m])
リアルタイムで異常検知とアラートに寄せやすいので、allowlist から漏れている通信先や、不要な管理アクセスの兆候を見つけやすくなります。
結果
設計として整理できたのは、次の四点です。
- CRS304 をいまの VDSL ではルーター兼スイッチとして十分使える
- Mac と Linux のローカル高速転送を維持したまま外向き通信を絞れる
- Wi-Fi 系を別セグメントに逃がして有線ローカルと役割分離できる
- 監視基盤まで含めて、後からポリシーの不足を追跡できる
特に、「ローカルは有線」「外向きは Wi-Fi または明示的に許可した経路」「将来 FTTH に移ったら CRS304 をスイッチ専用へ寄せる」という流れがきれいに整理できたのが大きかったです。
議論と今後
この構成は、現時点の VDSL とローカル 10GbE の両立にはちょうどいいですが、将来の FTTH 移行では再評価が必要です。外向きの高速ルーティングやフィルタの数が増えると、CRS304 の RouterOS ルータ運用はどこかで限界が見えてきます。そのときは本格ルーターを追加し、CRS304 は SwOS で 10GbE スイッチに専念させるのが自然です。
いまの段階では、まずこの設計で運用を安定させ、drop ログと帯域の傾向を見ながら allowlist を磨き込むのが先です。必要なものだけ通し、普段は外へ出さない、という原則を崩さないまま、使い勝手を詰めていきます。
