すべての始まり：自宅ネットワークの限界
自宅のネットワーク環境はひどい状態だった。子どもがYouTubeを見始めると、ビデオ通話が固まる。DNSクエリはISPのサーバーに漏れていた——信頼する理由がまったくないサーバーに。派手なLEDが光る「ゲーミングルーター」は？深夜2時に誰が回線を食い潰しているか、まったく教えてくれなかった。
6ヶ月前、3台のルーターにOpenWrtを書き込んだ：TP-Link Archer C7、Linksys WRT3200ACM、そしてRaspberry Pi 4をサブルーターとして有線接続したもの。結論から言えば——動く。しかし、たいていのガイドが触れない部分に落とし穴が多く、日常的に本当に重要なことがほぼ省略されている。
根本原因：メーカー純正ファームウェアは機能の砂漠
これまで触れてきた純正ルーターファームウェアはどれも、一点だけを最適化している：10分でネットにつなぐこと。ネットワーク制御は後付けの発想だ。デバイスごとの帯域制限？隠されているか存在しない。フォールバックリゾルバー付きのDNS-over-TLS？コンシューマー向けUIで見つけられたら奇跡だ。プロトコル別のリアルタイムトラフィック表示？それは500ドルのエンタープライズ製品の機能だ。
セキュリティはさらに深刻だ。ISP支給のルーターはいまだに2019年のカーネルで動いている——3年分の未パッチCVEが、自分のデバイスとインターネットの間に座っている。OpenWrtはセキュリティアップデートを積極的に提供し、完全なLinux環境を手渡してくれる：opkgパッケージマネージャー、iptables/nftables、LuCI Web UI、そしてすべてへのSSHアクセス。
純正ファームウェアの本当のコストは、欠けている機能ではない。家庭内のすべてのパケットを処理するデバイスへの可視性を失うことだ。
検証した3つのアプローチ
選択肢1：DD-WRT
DD-WRTは2005年から存在する。対応機器リストは膨大で、それは認める。Archer C7で2週間動かしたが——UIはFirefox 3の時代から手が入っていない印象で、OpenWrtと比べるとパッケージが少なく、ビルドシステムが不透明だ。問題なく動く。ただ、自分のものを作っている感覚より、レガシーソフトウェアを保守している感覚が強い。
選択肢2：Tomato/FreshTomato
DD-WRTよりUIが洗練されていて、QoSの可視化は本当によくできている。しかし致命的な制限がある：Broadcomチップセット専用だ。これで手持ちの3台のうち2台が即座に脱落した。Netgear R7000や同等のBroadcomルーターを持っているなら、FreshTomatoは検討に値する。それ以外には行き止まりだ。
選択肢3：OpenWrt
OpenWrtは、自分が重視するすべての軸で勝った——6,000以上のパッケージ、活発な開発、透明なビルドシステム、WireGuardとnftablesの一級サポート。学習曲線は急だ。しかしLinuxなので、学んだことが確実に他に活かせる。
最善の選択：OpenWrtの導入から本番運用まで
ステップ1：まずハードウェアの互換性を確認する
何かを触る前に、OpenWrt Table of Hardwareを確認すること。対応機器でも品質は一様ではない。特にフラッシュサイズ（推奨最小16MB）とRAM（パッケージを快適に使うには最小128MB）を確認する。Archer C7 v2はよく動く。v5には既知の問題がある。バージョン番号はここでは重要だ。
ステップ2：ファームウェアを書き込む
正しいイメージをダウンロードする。2種類ある：factory（純正ファームウェアから書き込む場合）とsysupgrade（既存のOpenWrtをアップグレードする場合）。間違えるとルーターが文鎮化する——これは仮定の話ではない。
# 書き込む前にSHA256チェックサムを検証する
sha256sum openwrt-23.05.3-ath79-generic-tplink_archer-c7-v2-squashfs-factory.bin
# OpenWrtダウンロードページのチェックサムと照合する初回インストールは純正ファームウェアのWeb UIから書き込む。以降のアップデートはsysupgradeで問題なく対応できる。
ステップ3：SSHで初期設定を行う
書き込み後、有線LANで接続する——WiFiではない。そしてSSHで入る：
ssh [email protected]
# すぐにrootパスワードを設定する
passwdWANインターフェースを設定する。モデム配下の一般的な家庭環境では：
uci set network.wan.proto='dhcp'
uci commit network
/etc/init.d/network restartステップ4：DNS-over-TLSによるカスタムDNS
暗号化DNSがOpenWrtに乗り換えた主な理由だった。OpenWrtではstubby——DNS-over-TLSのスタブリゾルバー——とdnsmasqのローカルキャッシュを組み合わせてこれを実現する。両方インストールする：
opkg update
opkg install stubby luci-app-stubbyCloudflareまたはNextDNSを使うよう/etc/stubby/stubby.ymlを設定する：
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
listen_addresses:
- 127.0.0.1@5453dnsmasqがstubbyを向くように設定する：
uci set dhcp.@dnsmasq[0].server='127.0.0.1#5453'
uci set dhcp.@dnsmasq[0].noresolv='1'
uci commit dhcp
/etc/init.d/dnsmasq restart
/etc/init.d/stubby restart6ヶ月間、DNSの漏洩はゼロ。クエリのレイテンシはむしろ下がった——dnsmasqがレスポンスをローカルにキャッシュするため、よく使うドメイン（Google、YouTube、GitHub）の繰り返しのルックアップが、上流リゾルバーに毎回問い合わせる代わりに1ms以下で返ってくる。
ステップ5：WireGuard VPN
OpenWrtはバージョン21.02からWireGuardをネイティブサポートしている。パッケージをインストールする：
opkg install wireguard-tools luci-app-wireguard kmod-wireguardルーター上で直接鍵を生成する：
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
cat /etc/wireguard/privatekey
cat /etc/wireguard/publickeyUCIでWireGuardインターフェースを作成する：
uci set network.wg0=interface
uci set network.wg0.proto='wireguard'
uci set network.wg0.private_key="$(cat /etc/wireguard/privatekey)"
uci set network.wg0.listen_port='51820'
uci set network.wg0.addresses='10.0.0.1/24'
# ピアを追加する（ノートPC、スマートフォンなど）
uci add network wireguard_wg0
uci set network.@wireguard_wg0[-1].public_key='PEER_PUBLIC_KEY_HERE'
uci set network.@wireguard_wg0[-1].allowed_ips='10.0.0.2/32'
uci commit networkWireGuardトラフィックを許可するファイアウォールルールを追加する：
uci add firewall rule
uci set firewall.@rule[-1].name='Allow-WireGuard'
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].dest_port='51820'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].target='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart
/etc/init.d/network restartステップ6：SQMによるQoS（バッファブロートを解消する）
バッファブロートこそ、誰かがファイルをダウンロードするとビデオ通話が壊れる原因だ。ルーターのTXキューがいっぱいになり、すべてのパケット——ZoomのパケットもNetflixのチャンクもWindowsのバックグラウンドアップデートも——が同じ列で待たされる。誰も得をしない。
SQM（Smart Queue Management）とCAKEアルゴリズムを組み合わせることで、キューの深さを積極的に管理し、レイテンシ敏感なトラフィックを優先することでこれを解決する：
opkg install luci-app-sqm sqm-scriptsLuCI（ネットワーク → SQM QoS）またはUCIで設定する：
uci set sqm.eth1=queue
uci set sqm.eth1.interface='eth1' # WANインターフェース
uci set sqm.eth1.enabled='1'
uci set sqm.eth1.download='95000' # 実測ダウンロード速度の95%（kbps）
uci set sqm.eth1.upload='19000' # 実測アップロード速度の95%（kbps）
uci set sqm.eth1.qdisc='cake'
uci set sqm.eth1.script='piece_of_cake.qos'
uci commit sqm
/etc/init.d/sqm restart重要な点：速度の値はISPの公称値ではなく、実際に計測した回線速度の95%に設定すること。この余裕がCAKEにとって、ISP側のバッファが介入する前にキューを管理するための空間になる。DSLReportsのバッファブロートスコアがCからAに跳ね上がった。同じ回線で2人がゲームをしていても、Zoomの通話がピーク時間帯に途切れることがなくなった。
6ヶ月後：何が本当に機能し続けたか
DNSはゼロ介入だった。dns.leak-test.comで検出された漏洩なし、手動再起動なし、デグレードなし。WireGuardは4Gやホテルのネットワークからテストするたびに即座に接続できた——あらゆるケースでハンドシェイクは200ms以下。QoSの改善が最も即座に実感できた変化だった。ビデオ通話の品質に対する家族からの不満は、1週間以内に消えた。
継続的に注意が必要な点はパッケージの更新だ。OpenWrtは設計上、自動更新しない——利便性より安定性を優先している。月に一度確認する習慣を作ること：
opkg update && opkg list-upgradableトラフィックの少ない時間帯に更新を適用する。5分もかからない。
導入初日と6ヶ月後に何が変わるか
コマンドラインに慣れていなければ、初日は辛い。LuCIで一般的なタスクの多くはカバーできるが、少し凝ったことをしようとすると、ほぼ必ずUCIコマンドか直接のファイル編集に行き着く。本番ルーターとして使う前に、慣れるための週末を1つ確保しておくこと。
6ヶ月後は違う景色だ。ルーターは設定した通りに動き、それ以外のことは何もしない——テレメトリーが外部に送信されることも、強制的なファームウェア更新も、監査も無効化もできないバックグラウンド機能も存在しない。それが本当の見返りだ。個別の機能ではなく、自分が所有するハードウェアを完全にコントロールし、その上で動いているすべてを明確に把握できること——それこそが価値の本質だ。
