CRS304でローカル通信と外向き通信を分ける

CRS304のRouterOSでVLANとFirewallを設計しました。MacとLinuxの10GbE転送を維持し、Linuxの外向き通信を必要な宛先に絞る構成です。開発用インフラ構築で、ローカル転送と更新用の通信を分けます。

VDSLではルーター兼スイッチとして使います。Port2とPort3はローカル有線、Wi-Fi AP側は家庭内のインターネット接続用です。Linuxはallowlist、Macは制限を緩くし、ISPからのinboundはdropします。監視はPrometheusとLokiを使います。

必要な通信

Linuxは通常、ローカル開発と転送に使います。更新時だけapt、pypi、ghcr.ioなどへ接続したい構成です。常用端末、Wi-Fi、IoTとは通信の条件が異なります。

MacとLinux間は10GbEのまま使い、LinuxをWi-Fiだけに寄せない方針です。条件は次のとおりです。

  • Mac と Linux の間ではローカル高速転送を維持する
  • Linux は通常時に外部通信できないか、極小の allowlist に限定する
  • Mac は日常利用の自由度を落としすぎない
  • IoT / mobile は有線ローカル系から切り離す
  • ISP 側からの入力は例外なく遮断する
  • ログとメトリクスを後から追えるようにする

VLAN、stateful firewall、Linux用allowlist / denylistを組み合わせます。物理ポートの役割と、将来のFTTH移行も考慮します。

全体設計（要約）

ポートの役割です。

  • Port1 = WAN
  • Port2 = Mac または有線クライアント系
  • Port3 = Linux
  • Port4 = Wi-Fi AP trunk
  • Port5 = Console / 管理

基本のVLAN構成です。

  • VLAN10 = Wired-LAN
  • VLAN20 = Wi-Fi Trusted
  • VLAN30 = Wi-Fi IoT

有線はローカル中心、Wi-Fi APは家庭内の出口です。Linuxのnew接続をallowlistで制御し、WANのinputをdropします。監視はSNMP exporterとSyslog/Lokiです。

1) アドレス設計（例）

基本のアドレス案です。

  • 10.10.10.0/24 を有線 LAN
  • 10.20.20.0/24 を Trusted Wi-Fi
  • 10.30.30.0/24 を IoT Wi-Fi
  • WAN は DHCP クライアント

運用メモでは1.10から1.13を役割の略記として使っています。

デバイスIP用途
ONUISP 割当 (WAN 側)VDSL 回線終端
CRS3041.10ルーター / NAT / DHCP サーバ
Wi-Fi AP1.11無線クライアント配下
Mac1.12Linux との有線やり取り専用
Linux1.13Mac とのローカル転送主体、外向きは個別制御

10.xは実装用のセグメント、1.10から1.13は運用上の役割を示す表記です。

2) 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の外向き用途を2ゾーンに分けます。

  • 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は次の3役を担います。

  1. ONU に直結するルーター
  2. Mac と Linux のローカル高速転送を担う 10GbE スイッチ
  3. 家庭内 Wi-Fi とローカル有線を束ねる中継点

Port2とPort3の転送はL2スイッチングで、WANを経由しません。ローカルは有線で転送し、外向き通信をRouterOSで制限します。

IP・ルーティングの整理

運用上のIPとルーティングです。

デバイスIP用途
ONUISP 割当 (WAN 側)VDSL 回線終端
CRS304 (Router)1.10ルーター / NAT / DHCP サーバ
Wi-Fi AP1.11無線クライアントのゲートウェイ配下
Mac1.12Linux とのローカルやり取り専用
Linux1.13ローカル転送主体、外向きは限定許可

LinuxとMacの転送はローカルです。インターネット側はWi-Fi AP、CRS304、ONUを通る経路として分けます。

CRS304 の役割

ルーティングとローカル転送を1台にまとめる案です。

ルーターとして

ONUに接続し、NAT / DHCP / Firewallを担当します。100Mbps級VDSLでは、RouterOSの性能で対応できる見立てです。

スイッチとして

Port2とPort3をL2でつなぎ、10GbE転送に使います。別のローカルスイッチを置かずに済む案です。

ハブ的な統合点として

Port4のWi-Fi APで家庭内クライアントを別セグメントに収容します。

運用ルール

通信許可には、物理接続の条件も含めます。

  • 普段は Linux NIC3 を未接続にする
  • 更新するときだけ ether2 に挿す
  • 学習や一時取得のときだけ ether3 に挿す
  • Linux 側でも対応する IP と GW を切り替える

有線はローカル用、外部接続はWi-Fiか明示的に許可した経路とします。Linuxの設定、ケーブル接続、RouterOSの許可が揃わないと通信できない運用です。

3) Wi-Fi AP 側の設定（概念）

APのether4をtrunkにし、VLAN20とVLAN30をタグ付きで通す前提です。

  • SSID1 を Trusted 側に割り当てる
  • SSID2 を IoT 側に割り当てる

Wi-Fi側のインターネット利用を、有線Linuxの制限から分けます。

追加で検討する機能

拡張候補です。

  • AdGuard Home を前段に置いて GUI で allowlist / denylist を管理する
  • IoT と Trusted の間で mDNS 中継が必要なら専用プロキシを入れる
  • log-prefix 付き drop ルールで不足している許可先を洗い出す

FQDNで宛先を管理する場合は、DNSの状態も確認できる補助ツールを検討します。

確認する項目

基本の確認項目です。

  • Linux が通常時に WAN へ出られない
  • dev-allow / temporary-allow を分けて差分管理できる
  • Wi-Fi Trusted と IoT が分離されている
  • VLAN 間は明示ルール以外で通らない
  • ルータ自身の管理面が WAN から露出しない

ローカル転送と監視も確認します。

  • Port2 / Port3 のローカル転送が WAN を経由せずに成立する
  • Mac は日常運用で窮屈にならない
  • Linux はローカル中心のまま、必要時だけ段階的に外へ出せる
  • 監視で drop / login failure / config change を追える

この構成のメリット

VDSLと10GbE転送

100Mbps級VDSLなら、CRS304でルーティングしつつローカル10GbEを使う構成を想定できます。高速WAN向けのルーターとしては別途評価が必要です。

FTTHへの移行案

光1G / 10Gへ移る際は、CRS304をSwOSのスイッチ専用にし、CCR、RB5009、L009などを前段に置く案です。

常設時の電力

消費電力の目安は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（ルーター/フィルタ性能）

CPUが関わるRouterOS経路の性能です。

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へ移る際は再評価します。

物理構成と運用方針 

  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などを許可し、他はdropします。MacのPort2はoutbound newを制限しません。inboundは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の不足や不要な管理アクセスを検知し、アラートにつなげる想定です。

設計で整理したこと

整理した点は次の4つです。

  • CRS304 をいまの VDSL ではルーター兼スイッチとして十分使える
  • Mac と Linux のローカル高速転送を維持したまま外向き通信を絞れる
  • Wi-Fi 系を別セグメントに逃がして有線ローカルと役割分離できる
  • 監視基盤まで含めて、後からポリシーの不足を追跡できる

運用と移行時の確認

FTTHで高速なルーティングや多数のフィルタが必要になったら、専用ルーターを追加し、CRS304をSwOSの10GbEスイッチにする案を再評価します。

まずはdropログと帯域を確認し、必要な宛先だけallowlistへ追加します。