L2/L3 設計・DNS・オブザーバビリティ

L2/L3 設計とブロードキャスト抑制

家庭向け・SOHO向けの機器では難しい、L2/L3 のフィルタリングを IX2215 で行い、まともなLAN環境を構築しています。

その中身は 60行ほどの ACL です。通常のネットワークではありえない量ですが、裏を返せば、既存環境はそれだけのフィルタを書かないと静かにならないほど汚染されているということです。

フィルタは大きく3系統に分かれています。

• blockl2 — 特定 EtherType のL2フレームを遮断
• bdhcp — 学内LAN側からの DHCP(udp/67-68)を遮断し、問題2 のレース応答を PoC セグメントに持ち込ませない
• oldlan — NetBIOS、SNMP、SSDP、WS-Discovery、mDNS、LLMNR、プリンタ探索(BJNP 等)、Dropbox LAN Sync といった探索系トラフィックを IPv4/IPv6 の両方で遮断

この抑制の効果は 現状の課題 に載せた実測動画のとおり、無関係パケット 75% → 8% 前後です。

Unbound フルリゾルバをローカルに設置

DHCP で実際に配られている DNS を調べると、Google Public DNS(8.8.8.8)、Cloudflare(1.1.1.1)、Quad9(9.9.9.9)といったパブリックDNSがそのまま指定されていました。利用者はこれらの事業者へクエリを送信することにも、そのプライバシーポリシーにも明示的に同意していません。本来は不適切な構成です。

それだけならまだしも、建物によっては一部のドメインへの名前解決を返さない、検閲まがいのリゾルバまで配られていました。利用者に無断で、どのサイトに到達できるかを黙って左右するのは論外です。

本来、組織のリゾルバ運用として適切なのは、自回線の ISP へフォワードするか、フルリゾルバを自前で運用するかのいずれかです。ISP フォワードは、自回線の事業者であれば通信の秘密に縛られ、海外パブリック DNS よりずっと筋が良い。ただし本環境では契約 ISP(NURO)がリゾルバアドレスを公開しておらず、そもそも指定できません。加えてフォワードである限り、全クエリの集約ログは単一事業者に残り、その事業者による NXDOMAIN 書き換えや上流のフィルタにも従属します。

本PoCでは Proxmox VE 上に Unbound のフルリゾルバをコンテナで構築し、ルートから自前で再帰的に解決します。外部事業者への依存も第三者によるフィルタもなく、高速で安定した名前解決を提供しています。性能面は、dnsperf による実測で 100,000 qps まで捌けることを確認済みです。

なお、DNSSEC 検証は 明示的に無効化 しています。検証側に落ち度がなくても、権威側の設定ミスや鍵管理の事故で名前解決そのものが失敗し得るなど、得られる効果に対して運用上の障害リスクが見合わないと判断したためです。詳細は鈴木常彦先生の「DNSSEC はなぜダメなのか」を参照してください。

オブザーバビリティ

監視・テレメトリ・ログ集約の標準スタック(Prometheus / Grafana / SNMP / Rsyslog)を LXC で構築し、Grafana ダッシュボードを公開しています。

公開ダッシュボード: https://tukushityann.net/grafana/

ルーターのインターフェース状態、WLC に join した AP 数、サーバーのリソース、DNS の QPS まで、この構成の生存状態はすべてここで見られます。

仮想化による高い運用効率

WLC(C9800-CL)の VM も、各種サービスのコンテナも、すべてミニPC 1台の Proxmox VE 上に載せています。物理的な設置スペースと消費電力を抑えつつ、高密度で効率的なリソース運用を実現しています。