ネットワークと境界

サービスを動かす Mac はネットワークの中に存在し、現実のトラブルの多くはそのネットワークから始まります — WAN リンクが切れたルータ、誤ったサブネットに紛れたデバイス、何か月も前に開けたまま閉じ忘れたポート。FrontierStack は、ネットワークとその境界（LAN とインターネットの境目）を一級のオブジェクトとして扱います。ルータを直接読み取り、LAN をスキャンしてインベントリを作り、データフロー図を描き、外部へサービスを公開するための規律ある複数の方法を提供します。

本章はサーバを取り巻くネットワークを扱います。サーバ自体を SSH で連携する方法は第 8 章、ホストファイアウォール・fail2ban・セキュリティ監査は第 10 章、Cloudflare の DNS と TLS は第 7 章を参照してください。

9.1読み取り・操作できるルータとファイアウォール

FrontierStack は、管理 API があればそれを通じて、なければ SSH で、ネットワーク機器と対話します。最も緊密な連携は OPNsense（フル REST API）と Cloudflare（第 7 章）の 2 つで、より広範なルータ・ファイアウォール群はライブ状態を報告します。Router & Network ペインでアドレス・ベンダー・API キーを指定してデバイスを追加すると、AI 管理者の router_info ツールが バージョンとモデル、稼働時間、CPU・メモリ、WAN リンクとゲートウェイ（上／下）、インターフェイス、クライアント数を読み取れます — さらに FrontierStack がマップしないフィールドの生の API JSON も。読み取り専用で、デバイス自身の API を照会し、SSH は使いません。

OPNsense と pfSense では、API キーを設定すると継続的なファイアウォール監視（ピン留めデバイスのペインにあるトグル）が使えます。アラートのスイープごとにファイアウォール自身へゲートウェイ状態・インターフェイスのキャリア・サービスの稼働を照会します — マルチ WAN ルータがサイレントにフェイルオーバーして WAN 回線の死を隠しても（サーバは外に出られるのにサイトへのインバウンドは全滅）、原因不明の赤いドットの海ではなく、どのゲートウェイが落ち、どのポートがキャリアを失ったかを名指しで通知します。ルータには何もインストールしません。OPNsense の REST API は標準搭載、pfSense は REST API v2 パッケージのみ必要です。同じペインから OPNsense ルータをテイルネットに参加させることもできます。Mac 側で Tailscale にサインイン（Google アカウント可）して事前認証キーを発行し、デバイスペインの Tailscale セクションに貼り付けるだけで、FrontierStack が必要に応じて os-tailscale プラグインをインストールし、キーとログインサーバ（Headscale も可）を保存してサービスを API 経由で再起動します。ルータでのブラウザログインは不要です。参加後はテイルネットアドレスがフォールバックとして記憶されます。LAN アドレスが応答しなくなったとき（社外にいる、VPN 経路が落ちた、LAN 側が死んだ）、ステータス確認・監視・証明書更新は自動的に Tailscale 経由で再試行してその旨を表示し、監視は別途「LAN アドレス」のアラートを上げるので、経路の障害をルータの故障と取り違えません。

攻撃と障害の兆候。ゲートウェイを監視するのと同じスイープが、ルータ自身のトラブルも監視します。異常のあるルータはサイドバーでオレンジ＋警告三角になります — 理由はホバーで表示。侵入検知プラグインを有効にした OPNsense では、同じ API 経由で直近の Suricata アラートを読み取り、件数と上位シグネチャを表示します（ファイアウォール UI を開かずに攻撃の試みを可視化。pfSense の REST API は IDS を一律に公開しないため現状は OPNsense のみ）。すべての監視対象ルータ — OPNsense、pfSense、OpenWrt ほか — では各スイープが、予期しない再起動（稼働時間の急減：クラッシュ・電源イベント・攻撃）、ルータ管理／SSH への総当たりの急増（失敗ログインの連続。最も多い送信元 IP をルータ自身のログから名指し）、リソース逼迫（メモリまたは負荷が危険なほど高い — DoS・暴走／侵害されたプロセス）、利用可能なファームウェア更新（古いファームウェア＝既知の穴）も検出します。それぞれアラートを上げ、あるプラットフォームが報告できない兆候は単にスキップします — 誤った「異常なし」にはなりません。OPNsense と OpenWrt が最も多く報告し、pfSense の API はより限定的です。

証明書の期限。同じスイープがファイアウォールのトラストストア — サービスが使うすべての CA と証明書 — を読み取り、期限切れの 1 か月前に、そして期限切れ後にもアラートを上げます。これは誰も想定しない障害です：OPNsense の既定 397 日で発行された OpenVPN サーバ証明書は 1 年後に静かにすべてのリモートユーザを締め出し、Web GUI 自身の HTTPS 証明書が切れれば管理画面はブラウザ警告に変わります。デバイスペインは期限の近い順に色付きドットで一覧し、更新…ボタンがルータの API 経由で証明書をその場で再発行します：秘密鍵・サブジェクト・CA は同じまま、有効期間は選択可能（最長 10 年）、必要なら OpenVPN サーバと Web GUI を再起動して読み込ませます。鍵とサブジェクトが変わらないため、既存の VPN クライアントのプロファイルはそのまま動きます — 再エクスポートは不要です。pfSense では REST API の更新アクションが同等の処理を行い、依存サービスも自動で再起動します。pfSense の API は認証局（CA）の有効期限を報告しないため、FrontierStack は CA 証明書そのものから期限を読み取ります。これにより pfSense の CA も他と同様に警告されます。CA はどちらの API でも更新できません。CA の期限が早めに通知されるのは、置き換えに証明書の再署名とクライアントプロファイルの再配布が必要だからです。OpenVPN サービスペインには同じルータ証明書が、Mac 上の各 .ovpn プロファイル（OpenVPN Connect、Tunnelblick、最後に使ったファイル）に埋め込まれた CA とクライアント証明書と並んで表示されるので、クライアント側とサーバ側の期限を一目で比べられます。Plan & Cost カードには OpenVPN 自体は無料であることと、Access Server と CloudConnexa の料金も記載しています。

ルータの操作と診断。AI 管理者は読み取り以上のこともできるようになりました：reboot_router はサーバの再起動と同じ方法でアプライアンスを再起動し（OPNsense／pfSense は API、OpenWrt は SSH）、「Allow changes」でゲートされます。ルータ自身のコンソールで行う方が本当に適したタスクのときは、アシスタントが open_web_ui でその Web UI を開くことを提案します — アドレスは推測せずデバイスペインから解決します。FrontierStack 自身はこれらアプライアンスのファイアウォールルールを意図的に編集しません — OPNsense／pfSense／OpenWrt は独自の設定システムでルールを管理するため、ペインとアシスタントは代わりにネイティブのファイアウォールページを案内します（ルータを右クリック ▸ Open firewall rules… が直接移動）。ペインの利便機能が 2 つあります：Diagnostics ボタンは API 不要の到達性チェック（ping、よく使う管理ポート 80／443／8443／53、逆引き DNS、ゲートウェイ）を実行するので、API キーがなくてもルータをトリアージできます。またルータ／ファイアウォールでは、Discover Services がポートスキャンではなく Web UI を開くことを提案します（自分の境界機器をスキャンするのは通常望ましくありません）。OPNsense や pfSense への SSH が拒否される場合、SSH が無効になっているか — より多いのは — 特定のインタフェース（多くは WAN ではなく LAN）でのみ許可されているためです：LAN 経由（例：VPN 経由）なら通常つながり、外部からは通常ブロックされます。Web UI で SSH と待ち受けインタフェースを有効にしてください（OPNsense は System ▸ Settings ▸ Administration ▸ Secure Shell）。SSH ボタン自体が非表示になるのは、管理シェルをまったく持たない民生用ゲートウェイ（NTT、一部の TP-Link／FRITZ!Box）だけで、その場合は Web UI が唯一の入口です。

9.2ファイアウォールの状態・グラフ・電源

監視を有効にしたピン留め済みの OPNsense・pfSense・OpenWrt ファイアウォールは、自身の API から状態を報告します。そのペインでグラフ表示されるようになりました。CPU とメモリを 0〜100 の 1 つのチャートに、そしてロードアベレージと温度です。サンプルはすでに実行中の監視ポーリングから取得するため、追加の API 呼び出しは発生せず、アラートのスイープが進むにつれてグラフが埋まり、セッションのおよそ直近 6 時間分をカバーします。

プラットフォームごとに提供される情報は異なり、ペインには実在する値だけが表示されます。pfSense は瞬間的な CPU 使用率を、OPNsense は代わりにロードアベレージを報告します。温度は FreeBSD が読み取れるセンサをハードウェアが備えているかに依存します——仮想環境や ARM の構成では搭載されていないことが多く、値がない場合は「センサなし」であり故障ではありません。

ピン留めしたあらゆるデバイスに、サーバと同じようにスマートプラグをリンクできます。オン・オフ・電源再投入、そして計測対応プラグならリアルタイムの消費電力も表示されます。これはファイアウォールで特に重要です。動作不良時に SSH で到達できない唯一の機器だからです——到達に使うネットワークこそ、その機器が提供しているものです。OPNsense も pfSense も自身の消費電力は報告しない（FreeBSD が公開するのは温度センサであり電力ではない）ため、計測対応プラグがファイアウォールで得られる唯一の実測値です。電源再投入は確認を求め、ファイアウォールを通過する全接続が切断されることを警告します。まず API 再起動をお試しください。

9.3Device Discovery：LAN のインベントリ

Device Discovery を開き、Find Monitors を押します（先にサブネットを選んでも構いません）。FrontierStack は選んだ /24 を利用可能なすべての方法で一斉にスイープし、ルータ・アクセスポイント・スイッチ・NAS（Synology、QNAP、ZimaCube／ZimaOS など）・プリンタ・カメラ・他のサーバをまとめて浮かび上がらせます。

• Ping／ARP — ICMP スイープ。ARP／MAC が各ホストのベンダーを示します。TCP Probe をオンにすると、ICMP をフィルタするホストも見つかります。
• Bonjour（mDNS）と SSDP／UPnP — アドバタイズされたサービスとそのフレンドリ名。
• SNMP と LLDP／CDP — net-snmp と lldpd をインストールするとモデル・ポート・近隣の詳細が加わります（ペイン内のボタンでインストール）。
• Windows サービスポート — ICMP をフィルタするマシンも、特徴的なポート（RDP・WinRM・SMB など）を探ることで見つかるため、Windows PC がスイープから隠れることはなくなりました。

スキャンは各ホストの到達方法も記録します。ローカルで AnyDesk が稼働中、または既定ポート 7070 で応答すると AnyDesk バッジが付き、この Mac 自身の tailscale status から Tailscale バッジ（ピアがオンラインなら緑）が付いてメッシュのピアを検出デバイスに対応付けます（保持するのはエンドポイント・ホスト名・OS のみで、ログイン名は保持しません）。直接接続の LAN では、macOS が既に Bonjour で把握している Mac やデバイスが低速な IP スイープより先に現れ、一覧がすばやく埋まります。デバイス詳細には対応する AnyDesk／Tailscale 行とアプリを開くショートカットがあります。

AI 管理者の discover_devices ツールは同じスキャンを実行し、種別を確信を持って識別できたデバイスを自動でピン留めします。あいまいなものは推測せず一覧に戻すので、アシスタントはそれが何かをあなたに尋ね、pin_device でピン留めできます。ピン留め（監視）されたデバイスはその種別のサイドバーセクションに現れ、ダブルクリックでペインを開けます。行の Open Web UI・Discover Services・Reclassify・Remove も使えます。アドレスが分かっていれば Add a device by IP フィールドが直接プローブしてピン留めします — 全体スキャンは不要です。

9.4あらゆるメーカのカメラ

カメラペインは、FrontierStack が把握しているすべてのカメラを、映像を表示できるかどうかに関係なく 1 つにまとめた状態ボードです。Device Discovery で見つかったカメラ（ピン留め済みと、見つかったが未ピン留めのもの）、AV Feeds のストリーム、SwitchBot のカメラ、Smart Life のカメラ、UniFi Protect のカメラを集めます。カメラが何十台あっても、上部の台数とオフラインフィルタですぐにわかります。オフラインのカメラが先頭に並び、ピン留めしたカメラと同じアドレスのストリームは、2 つに分かれずそのカメラのタイルに表示されます。ピン留めしたカメラと同じ MAC アドレスの Protect カメラは、そのカメラのタイルに表示します。各タイルのベルでオフラインのアラートを切り替えられ、すべてにアラートで確認できるカメラすべてをまとめて対象にできます。アラートはアラートペインを通るので、連絡先のプリセットで現地の技術者を呼び出せます。

カメラは、RTSP（ポート 554）、Web ポート（80）、ONVIF（2020）のいずれかに応答すれば稼働中とみなします。Ring・Nest・Blink・Arlo などクラウド専用のカメラは、自社アプリからしか届かないため状態を表示しません。

Tapo カメラを外出先から確認（非公式）。サービス ▸ カメラ ▸ Tapo Cameras で TP-Link ID でサインインすると、Mac が自宅のネットワークの外にあっても各 Tapo カメラのオンライン / オフラインがわかり、アラート経由でオフライン通知を受け取れます。TP-Link は公式 API を提供していないため、FrontierStack は Tapo Android アプリと同じ方法でサインインします。そのため TP-Link がアプリを変更すると動かなくなることがあり、利用が TP-Link の規約に反する可能性があります。読み取るのは状態だけです。パスワードは保存せず、2 回続けてオフラインと確認されたときだけオフラインとみなします。TP-Link のクラウドに接続できないときは状態を取得できませんと表示し、オフラインにはしません。ピン留めした Tapo カメラは、クラウドがオンラインと報告している間はネットワークの外でも緑の表示のままです。その他の Tapo デバイスや、2 つ目のサインインで Kasa デバイスも監視できます。

SD カード。Tapo、Hikvision/Annke、Dahua/Amcrest/Lorex、Reolink、Axis のカメラでは、各タイルにカメラ自身が報告するメモリカードの状態も表示します：SD ✓ 42% 使用、SD カードなし、未フォーマット、SD カードのエラー、不明のときは SD —（理由はポインタを重ねると表示）。FrontierStack はクラウドではなくカメラ自体のローカル API に、Mac がカメラのネットワーク上にいる間だけ問い合わせます。ネットワークの外では、最後の結果を確認時刻とともに表示したままにします。確認は 30 分ごとに 1 台ずつ、カメラごとに最短 10 分間隔で行います。Tapo 以外のカメラは、AV Feeds のストリームのログインか、カメラのデバイスペインで入力したログインを使います。Tapo カメラには admin と TP-Link アカウントのパスワードが必要で、Tapo Cameras ▸ ローカルカメラアクセスで一度入力します。パスワードはキーチェーンに保存し、TP-Link のクラウドに送ることはありません。カメラがログインを拒否すると、ログインを直すか再試行を押すまで問い合わせを止めます。カメラはサインインの失敗が続くとアカウントをロックするためです。接続やサインインができないカメラを「カードなし」と報告することはありません。SD のアラートは任意で、満杯に近いときのアラートは初期設定でオフです。ほとんどのカメラはループ録画のため、常に満杯に近いからです。eufy、WTW、Eseecloud のカメラにはストレージを読み取るローカル API がありません。

メーカごとに必要なこと：

9.14.1WTW のカメラとレコーダ

古い IP カメラ。WTW 自身の 2018 年版 IP カメラ取扱説明書では、メインストリームが rtsp://ip:554/live/0/main、サブストリームが /live/0/sub です。ポート 554 が既定で、変更できます。RTSP はカメラの Web 設定のネットワーク設定でオンにします。現行の PoE／IP モデルと NV4 シリーズのレコーダは、仕様に RTSP と ONVIF を記載しています。上記のパスで接続できない場合は、NVR アプリで ONVIF として追加して URL を調べてください。

EAGLE Wi-Fi シリーズ。RTSP にも ONVIF にも対応していません。WTW のサポートサイトはあるカメラについてそう明記しており、レコーダの仕様には TCP/IP・DHCP・P2P しか記載がありません。これらでできるのは、レコーダが Web ポートに応答するかの確認までです。Device Discovery で WTW Camera / NVR としてピン留めし、オフラインのアラートをオンにしてください。

初期パスワード。NV4 レコーダは 00000000 で、工場出荷時に戻すと wtwjapan になります。古いカメラは admin で空パスワード、または admin／admin です。ネットワークにつなぐ前に変更してください。

9.14.2スマートホームのクラウド

Smart Life（Tuya）の機器は、Tuya 公式の Cloud API で読み取ります。iot.tuya.com でアカウントのデータセンタ（日本のアカウントは Western America）に Cloud プロジェクトを作り、Devices ▸ Link Tuya App Account で Smart Life のアカウントを連携し、プロジェクトの Access ID と Secret を Smart Life ペインに貼り付けます。これで各機器のオンライン状態とプラグの電力が見え、プラグや照明のオン／オフができ、どの機器もオフラインになったらアラートを出せます。無料トライアルは月に約 26,000 回の呼び出しまでで、数か月ごとに延長が必要なため、FrontierStack は 10 分ごとに確認します。

Minut のセンサは、賃貸物件の騒音・在室人数・温度・湿度を報告します。Minut ペインは、センサのオフライン、バッテリ残量の低下、物件で騒音トラブルが進行中のときにアラートを出します。Minut は承認したアカウントにしか API を開放しておらず、ヘルプ記事ではエンタープライズプランが条件とされています。

SmartThings、Govee、LIFX、Sensibo、Nuki には、それぞれ専用のペインがあります。アカウントのデバイスを一覧にして、状態を色で示します。緑はオンライン、赤はオフライン、灰色はクラウドが状態を返していないことを表します。デバイスの横のベル、またはすべてアラートをオンにすると、オフラインになったときにアラートを出します。Govee、LIFX、Sensibo、Nuki に必要なのは、各社のアプリやサイトで発行する API キーかトークンだけです。SmartThings では、SmartThings CLI で自分用の OAuth アプリを一度作っておくと、サインインが切れずに使えます。個人用アクセストークンでも使えますが、24 時間で失効します。キーが拒否されたりサインインが期限切れになったりすると、アカウントのアラートを 1 件出します。クラウドに到達できないときは、そのデバイスを不明として扱います。どちらの場合も、デバイスのオフラインとは報告しません。賃貸物件では Nuki のロックを監視しておくと安心です。接続が切れたロックは、ゲストのために遠隔で開けられません。

9.5Data Map

Data Map ペインはロケーションごとのデータフロー図を描きます。1 つの拠点で、データがどこに存在し、デバイスやサービスを横断してどう流れるかを示します。FrontierStack はそのロケーションのインベントリ — 検出したデバイス、その役割、（任意で）スキャンしたポート — をシリアライズし、秘密情報を伏せて、ローカルの claude CLI を通じてあなたのサブスクリプション Claude に渡します（アプリ内ハーネスが使う従量課金 API ではありません）。返答は Mermaid フローチャートと短い説明として戻り、ペイン内でオフライン描画されます。各ロケーションの最新図は保持され、Obsidian ボールトにランブックとして保存できます。ロケーション自体は第 8 章で説明します。

9.6ポートを開く：UPnP と NAT-PMP／PCP

従来の方法でインターネットからサービスへ到達するには、ルータのポートを Mac へフォワードする必要があります。手作業でルータにログインさせる代わりに、FrontierStack はルータがアドバタイズする標準プロトコルでマッピングを依頼できます。

• UPnP IGD（miniupnpc 経由）— 一般的な家庭用ルータの方法。
• NAT-PMP／PCP（libnatpmp 経由）— Apple 由来の方式とその現代的後継。
• OPNsense — その API を通じて境界ルールとポートフォワードを直接設定。

これらのツールは初回使用時にオンデマンドでインストールされます。一時セッション用に作ったマッピング（Debug Share 参照）は、セッション終了時に自動で撤去されます。

9.7ダイナミック DNS：変化する IP を追う

家庭や小規模オフィスの回線は静的 IP を持たないことが多く、今日のアドレスに向けたホスト名は明日には古くなります。Dynamic DNS ペインはホスト名を現在のパブリック IP に追従させます。Name、Hostname（例 myhost.duckdns.org）、プロバイダのアカウント情報でエントリを追加し、Update Now で即時公開するか、Update automatically をオンにします。更新を FrontierStack の実行中のみ行うか、システムサービスとして恒久的に行うかを選べるので、アプリを閉じてもレコードは最新に保たれます。Cloudflare ユーザにはより緊密な経路があります — パブリック IP を追う Cloudflare DDNS A レコードで、第 7 章と同じ Cloudflare 連携が動かします。他プロバイダは更新 URL による汎用インターバル更新がカバーします。

9.8トンネルとメッシュ：開けずに届く

外部からサービスへ到達するより良い方法は、受信ポートを完全に省くことです。トンネルは外向きの接続を張り、外部エンドポイントがそれに乗って戻ってくることで、何もフォワードせず NAT を越えます。

• Cloudflare Tunnel — クイックトンネルはアカウント不要で公開 *.trycloudflare.com URL を、名前付きトンネルは恒久的なホスト名を与えます。
• Tailscale — Serve はサービスを tailnet 内で非公開に保ち、Funnel は Tailscale ノードを通じてインターネットへ公開します。

マシン間の継続的な接続には、メッシュ／VPN ネットワークが、どこへ移動しても各ノードに安定した私的アドレスを与えます。FrontierStack は一般的なものを管理します — 対応ルータ（OPNsense）では API で、サーバでは SSH で。

9.14.3テイルネット：Tailscale 全体のビュー

サーバごとの Tailscale 操作は各サーバのペイン内にあり、SSH 経由で「そのマシンでデーモンが動いているか」を確認します。テイルネットペインは、Tailscale 自身の API でしか分からないネットワーク全体の状況を扱います。API アクセストークン（このペインは書き込みを行わないため、デバイスの読み取り権限だけで十分）を貼り付けると、各デバイスのアドレス、OS、クライアントバージョン、所有者、タグ、最終確認時刻が一覧表示されます。

このペインの価値は「要対応」リストにあります。期限が近づいたノードキー（キーが失効するとデバイスは静かにテイルネットから外れ、再認証するまで戻りません＝予定された障害）、承認待ちのデバイス、承認されていないルートを広告しているデバイス（ノードは正常なのにサブネットへ到達できない典型的な原因）、そして数週間チェックインしていないデバイスを表示します。キーの期限切れと承認待ちはアラートにも通知されます。

9.14.4自前の ZeroTier コントローラを運用する

ZeroTier のクライアントはメンバ側だけで、ネットワークの管理は通常 my.zerotier.com で行います。しかし zerotier-one はどのインストールでも、そのネットワークのコントローラ自体になれます。完全にセルフホストでき、メンバ一覧を第三者に預ける必要もありません。ただしこの構成にはローカルの管理 UI が一切付属しません。ZeroTier コントローラペインがその欠けた部分を埋めます。

コントローラの identity と所有するネットワークを表示し、メンバの承認キューをワンクリックの承認／取り消しで処理できます。承認済みでも 2 週間確認されていないメンバには印が付きます。使われていない許可はネットワークの穴になり続けるためです。ネットワーク名、公開／非公開、ルート、IP 割り当てプールを編集でき、ZeroTier 独自のルール言語でフロールールを記述できます。入力しながらローカルでコンパイルされ、よくある構成のテンプレートに加えて、全員を締め出すルールセットを保存する前に警告が出ます。

すべての操作はコントローラ自身のループバック API に対して SSH 経由で行われます。コントローラは 127.0.0.1:9993 で待ち受け、root 権限で読めるトークンで認証するため、FrontierStack はコントローラ API を外部に公開する必要がなく、むしろ公開しない設計です。内蔵の監査は、誰かが公開してしまっている場合や、ファイル権限が緩い場合、バックアップがない場合に警告します。Prometheus への書き出し、ウォームスタンバイのバックアップ／復元、ZeroTier Central からの移行アシスタントも用意しています。

9.9UniFi：クラウドゲートウェイ、Dream Machine、Superlink

Ubiquiti のコンソールには専用ペインを用意しています。UniFi ゲートウェイは、汎用のルータ監視では見えない仕事をしているためです。Dream Machine（UDM、UDM Pro、UDM SE）、クラウドゲートウェイ（UCG-Ultra、UCG-Max、UXG）、Superlink ゲートウェイ、Cloud Key、セルフホストのコントローラのいずれにも対応します。UniFi ペインは Ubiquiti の 2 つの API を扱います。両者は答える問いが異なります。Site Manager キー（unifi.ui.com で作成する 1 つのキー）は、アカウント内の全コンソールを機種・ファームウェア・オンライン状態とともに一覧します。遠隔サイトが電源やインターネットを失ったことを知る唯一の方法です。ネットワークから切り離されたコンソールは、ローカルでは何も伝えられないからです。コンソール側（設定 ▸ 管理者とユーザ）で作成するローカル API キーは、ゲートウェイの現在の動作を明らかにします。

ローカル接続では、WAN 回線を ISP・レイテンシ・スループットとともに表示し、実際に通信を担っている回線を示します。この点が重要です。プライマリ回線が落ちると UniFi は無言でバックアップに切り替えますが、バックアップは多くの場合低速で従量課金です。通常これに気付くのは翌月の請求書です。さらに、アダプト済みデバイスとファームウェア、ゲートウェイが評価する順序どおりのファイアウォールルール、クライアント一覧、そしてすべてのポートフォワードを表示します。有効なポートフォワードはいずれもファイアウォールに意図的に開けた穴なので、任意の送信元アドレスからの接続を受け付けるものには印を付けます。公開ウェブサーバなら妥当ですが、それ以外では確認する価値があります。

アラートは、コンソールのオフライン、WAN 回線のダウン、バックアップ回線での稼働、デバイスのネットワーク離脱、インターネットに開放されたポートフォワードを対象とします。このペインは意図的に読み取り専用です。ルールやネットワークの変更は、その検証機構がある UniFi コンソール側に残します。PoE のポート制御は次節が扱い、コンソールの単純な到達性は従来どおり Router & Network にも表示されます。

Site Manager キーで UniFi Protect のカメラとドアベルも一覧します（最大 5 分ごと）。カメラのアラート、またはすべての Protect カメラでアラートをオンにするとオフラインを通知します。更新中のカメラや、コンソール自体がオフラインのカメラは、ダウンではなく不明と表示します。

9.10Power over Ethernet：電源ボタンのない機器の電源ボタン

アクセスポイント、カメラ、ドアコントローラ、デスクフォンには電源スイッチがありません。唯一の電源は接続先のスイッチポートです。そのため、応答しなくなった機器の復旧手段である「電源を入れ直す」には、通常ベンダの Web UI にログインするか、キャビネットまで歩く必要があります。

Power over Ethernet ペインは、そのポートをボタンに変えます。管理スイッチを IP で追加すると、ポートごとに PoE の状態（給電中、検索中、障害）、受電機器のクラス、優先度、スイッチが報告していれば消費電力が表示され、電源のオン／オフと電源の入れ直しが行えます。さらにスイッチの電力バジェット（総容量、使用中の電力、スイッチ自身の使用率しきい値の超過警告）も表示します。しきい値を超えるとスイッチは優先度の低いポートから給電を止めるため、ポート優先度もここで変更できます。

幅広く動作するのは PoE が標準化されているからです。RFC 3621 の POWER-ETHERNET-MIB は、ほぼすべての管理スイッチ（Cisco、Aruba/HPE、Netgear、TP-Link/Omada、Ubiquiti、MikroTik、D-Link、Zyxel）が実装しています。読み取りにはデバイス検出の SNMPv2c／SNMPv3 プロファイルを使います。SNMPv2c のポート電源操作には別の読み書きコミュニティをスイッチごとに設定し、Keychain に保存します。SNMPv3 は、認証済みユーザにスイッチ側で書き込み権限がある場合だけ同じプロファイルを使います。電源を切る操作には意図的な権限と確認が必要で、任意 OID 書き込みは公開しません。監視を有効にすると、障害状態のポートや電力バジェットを超えたスイッチがアラートに上がります。

9.11インターネットヘルスと速度テスト

Internet Health ペインは回線そのものを見るための画面です。Targets の一覧（既定では Cloudflare の 1.1.1.1、Google と Quad9 の DNS、AWS の 2 リージョン、Tailscale のコーディネーションサーバ）を継続的に ping し、レイテンシとパケットロスを表示して 30 秒ごとに再テストします。ICMP をブロックするホストは :443 への TCP 接続レイテンシにフォールバックします。対象一覧の編集は、Internet セクションのヘッダにある歯車ボタンで開くダイアログから行います。一度設定すれば邪魔になりません。同じセクションには IPv6 の判定も表示されます。スイープごとに、グローバル IPv6 アドレスの割り当て、IPv6 トラフィックが実際に機能するか（Cloudflare／Google の v6 エニーキャストへの ping）、ネットワークが広告する IPv6 DNS サーバが応答するかを確認します。最も強く警告するのは広告されているのに壊れている IPv6 です。ルータがアドレスと IPv6 DNS サーバを配布し、接続は IPv6 を先に試すため、IPv4 へのフォールバックまですべてが固まる状態です。ペインは分かりやすい言葉で状況を示し、応答しない DNS サーバを名指しし、ルータが原因であることを示します。AI 管理者は internet_speed（check=ipv6）で同じ診断を実行でき、diagnose ツールの ping6／dig／scutil でさらに詳しく調べられます。サイドバーのインターネットヘルス行にはステータスドットが表示され、軽量なバックグラウンドスイープ（起動時、その後 5 分ごと）で更新されます。正常なら緑、IPv6 の故障や大きなパケットロスはオレンジ、すべての対象に到達できない場合は赤になります。Live Traffic は全アクティブインターフェイスのリアルタイムスループットをグラフ化し、Addresses & Networks は各インターフェイス、そのサブネット（直接到達できるネットワーク）、ゲートウェイを一覧します。組み込みの traceroute は、トラフィックが横切る ISP やトランジット事業者を示します。Speed Test セクションで Test Now を押す — または AI に internet_speed を頼む — と、ダウンロード・アップロード・レイテンシ・応答性を測定します。Ookla の speedtest CLI があればそれを、なければ Apple の networkQuality を使います。実行中は speedtest.net 風の 2 つのメータがダウンロードとアップロードをリアルタイム表示します — 針・フェーズ・現在の Mbps を Ookla のストリーミング出力から更新します（内蔵の networkQuality は最後にしか結果を返さないため、メータは待機表示になります）。また、接続したテストサーバ（プロバイダと都市）を実行中と結果の両方に表示します。テストが失敗した場合は、何も表示せず終わるのではなく理由を表示します。ただし Wi-Fi 接続の Mac では、ISP と同じくらい Wi-Fi 自体を測ってしまいます。そこで同じセクションからテストをルータや有線サーバ上で実行できます。ルータ／サーバからでデバイスを選ぶと、FrontierStack が SSH（鍵認証。ルータは root）でそのデバイス上にプローブを実行します。Ookla／speedtest-cli があればそれを、なければ curl による単一ストリームの推定値を使います。ルータ側の測定値が Mac より大幅に速ければ、ボトルネックは回線ではなく無線区間です。AI も internet_speed の source で同じ比較ができます。

9.12ネットワークパス：スイッチ・ハブとホップごとの遅延

ネットワークパスペインは、IP ツールでは答えられない物理的な問い — この通信は実際にどの機器を通り、どれが遅くしているのか？ — に答えます。LAN パスはマネージドスイッチのブリッジテーブルと LLDP 隣接情報を SNMP で読み取り、この Mac と LAN デバイスの間のつながりを図示します。各リンクにポートと速度を表示し、最も遅いリンクを強調。1 つのポートを複数のデバイスが共有している箇所には、直接問い合わせできない隠れたアンマネージドスイッチ／ハブを推定として破線で描きます。デバイスを特定は 1 台を突き止めます：IP・MAC・メーカー・種類、そして接続されているスイッチポートまで。ビジュアルトレースルートは各ホップの往復時間をグラフ化し、遅延を最も追加しているホップを強調します。スイッチの読み取りにはデバイス検出で設定した SNMPv2c／SNMPv3 プロファイルを使います。アンマネージド機器は本質的に見えないため推定表示します。開くと、この Mac とルータの間を自動で図示し、デバイスリンク速度は既知デバイスのネゴシエート速度をスイッチポートから調査して、遅いリンクと半二重を先頭に表示します。

9.13Debug Share：localhost サーバを一時的に公開

localhost で動く開発サーバを同僚やスマホに見せたいとき、Debug Share ペインがそれをセッション中だけ公開し、その後自ら閉じます。ポートを入力（または Scan localhost で稼働中のサーバを検出）し、Expose via で公開方法を選び、Auto-close 時間を設定して、Open debug session を押します。すべての共有は FrontierStack 終了時にも自動で閉じます。

LAN フォワーダには 2 つの追加機能があります。ホストファイアウォールがオンなら、ペインに Open port in firewall が現れ、そのポートをセッション中だけ pf ルールで許可します。また Outside access ピッカーで UPnP・NAT-PMP・OPNsense API 経由の WAN ポートをマップし、DDNS host と組み合わせれば、LAN 共有をパブリックインターネットから到達可能にできます — マッピングは共有終了時に削除されます。AI 管理者もセッションの開始・一覧・終了ができます（debug_share_open／_list／_close）。「Allow changes」がオンなら MCP 経由でも可能です。

Debug Share のセッションはあくまで一時的です。自分の開発サーバを期限なしでテイルネットから開けるようにしておきたい場合は、Localhost ペインでサーバのTailscale でも公開をオンにします（第 4 章）。同じポートでこの Mac の Tailscale アドレスに公開され、LAN からは到達できず、サーバの停止とともに閉じます。AI 管理者は debug_share の action serve でフォルダをそのように起動し、開くべきアドレスを報告できます。

9.14名前付きトンネル：恒久的な公開ホスト名

クイックトンネルはあえて使い捨てです。この Mac のサービスを実際のアドレスで恒久的に到達可能にしたいとき — セルフホストのアプリ、社内ダッシュボード、Webhook 受信口など — は、代わりに名前付きトンネルを使います。サービスに自分の Cloudflare ゾーン上の安定したホスト名（例：app.example.com）を与え、再起動しても維持され、他のトンネル同様に着信ポートを一切開きません：Mac が Cloudflare のエッジへダイヤルアウトするため、フォワードするものも、ポートスキャンで見つかるものもありません。

Cloudflare ペインの名前付きトンネルセクションで作成します：新規トンネル…、続いて自分のゾーン配下のホスト名と、その前段に置くローカルポート。FrontierStack はすでに保持しているトークンを使い、Cloudflare API 経由でセットアップ全体を実行します — トンネルを作成し、イングレスルール（hostname → http://localhost:PORT）を書き込み、ホスト名を <id>.cfargotunnel.com に向けるプロキシ済み CNAME を追加し、cloudflared service install で永続デーモンをインストールします。最後の手順には一度きりの管理者プロンプトが必要です（/Library 配下に LaunchDaemon を書き込みます）。cloudflared 自体は初回利用時に Homebrew から取得されます。トンネルと DNS の作成だけを行い、cloudflared を別ホストで実行したい場合は、この Mac で今すぐ実行のチェックを外します。削除はそのすべて — デーモン、DNS レコード、アカウント側のトンネル — を巻き戻します。AI 管理者も同じ 3 つの動詞（tunnel_create／tunnel_list／tunnel_delete）を持ち、作成はサービスをインターネットに公開するため赤い確認でゲートされます。