NAT内のルーターをFleetdへ接続する：機器の承認と再接続の仕組み

クラウドサーバーを管理画面につなぐ手順は理解しやすいものです。プログラムを入れ、接続先を設定し、通信を確認します。家庭のルーターでは、公衆IPv4がなく、モデムや事業者のネットワークの内側にいることもあります。ポート転送、動的DNS、踏み台を整えると、管理用の入口自体が保守対象になります。

Fleetdの紹介では、エージェントから接続する方式に触れました。今回はv0.3.0の実装に沿って、接続方向、機器の承認、切断後の動きを説明します。

Fleetdは自分のサーバーやルーターを管理画面につなぐものです。汎用的なトンネルサービスでも、ルーター配下のLAN全体を自動公開する仕組みでもありません。

接続を始める側を逆にする

管理画面が家庭のルーターを探す代わりに、ルーターのエージェントがサーバーへ接続します。到達可能なサーバーにWebSocketを張り、監視データや後続の要求をその接続で運びます。

Linuxサーバー上のエージェントもNAT内のエージェントも、fleetd-serverへ向かって接続します。サーバーはPostgreSQLにデータを保存し、管理者はWeb画面を使います。

管理対象にFleetd専用の着信ポートを開ける必要はなく、サーバーが各ルーターの現在の公開アドレスを調べてから接続する必要もありません。

ただし、エージェントからサーバーへ到達できることは必要です。DNS、送信側の制限、プロキシ、通信品質は影響します。公開ドメインでも、到達可能なプライベートネットワークでも構いません。既存のWireGuardネットワークも利用できます。

NATの内側から使えるとは、接続方向を変えるという意味です。送信制限を回避したり、双方から到達不能なサーバーを自動的に利用可能にしたりするものではありません。

管理画面が開くことと、エージェントがつながることは別

ブラウザーでログインできても、エージェントが接続できない場合があります。画面とAPIへの経路に対し、エージェントには設定されたWebSocket接続先が必要です。

wss://fleetd.example.com/agent/ws

これは例示ドメインです。自分のアドレスへ置き換えます。リバースプロキシではWebSocketへのアップグレードと、長い接続を早期に閉じない設定が必要です。

トップページが正常でもWebSocket転送が抜けていれば、再インストールでは解決しません。接続先、プロキシログ、ハンドシェイクの失敗原因を確認します。

FleetdはWebSocket内にNoiseの暗号化セッションを構築し、エージェントはサーバー公開鍵を固定します。あるアドレスに到達しただけで、その先の任意のサーバーを信頼するわけではありません。

HTTPSの証明書とNoiseの固定鍵は別の確認です。誤った鍵や移行時の意図しない鍵変更でも接続は失敗します。本運用では引き続きHTTPSを使います。Noiseだけではブラウザーアクセスを守れず、通信の終点であるサーバーは受け取った監視データを読めます。

インストール前にエージェントを準備する

前回のCompose例で起動したのはサーバーとPostgreSQLです。署名付きエージェントの配布パッケージまでは自動生成しません。

継続運用では自分のリリース鍵を作り、対象アーキテクチャのパッケージを生成・アップロードしてから、管理画面の導入コマンドを使います。v0.3.0の公開バイナリーはLinux amd64とarm64です。ルーターのCPUを確認してください。

最初の1台はmonitor権限で接続と監視を試し、その後で操作権限を決めることを勧めます。

curl -fsSL https://fleetd.example.com/install.sh | sh -s -- --permission monitor

例示ドメインをそのまま実行せず、自分の管理画面から取得したコマンドの出所を確認します。インストーラーは強い権限で動きます。後の署名機構が、最初に取得したスクリプトの信頼性をさかのぼって保証するわけではありません。

スクリプトはsystemdまたはprocdに対応して設定を書き、サービスを登録します。設定内の鍵は役割が異なります。

情報	確認すること
サーバー公開鍵	接続先は想定したサーバーか
エージェントの識別鍵と指紋	どのエージェントが申請しているか
コマンド署名公開鍵	信頼する署名者が操作を認めたか
リリース公開鍵	信頼する公開者が更新を署名したか

通信失敗とコマンド拒否は別の検証に起因し得ます。適当な鍵を入れ替えて解決するものではありません。

承認待ちは正常な途中段階

エージェントは起動時に自分の識別鍵を読み込むか生成します。必要なハンドシェイクを完了した未知の識別情報は、承認待ちとして登録されます。

この段階で保存するのは名前、接続元、公開鍵などの登録情報で、通常の監視上報やコマンド処理にはまだ進みません。グラフがないことだけで収集処理の故障とは判断できません。

自分が管理する導入用ターミナルや既存の信頼できる接続で指紋を読み、管理画面と比較します。導入済みで設定パスが正しければ、次でも確認できます。

fleetd-agent -config /etc/fleetd/agent.yaml fingerprint

一致してから承認します。未知の申請が名乗るホスト名だけでは不十分です。IPも補助情報であり、複数機器の出口共有、アドレス変更、プロキシ設定の影響があります。名前とIPは見分ける助けになりますが、確認すべきなのは予定した機器の識別情報です。

承認と実行権限も別です。monitorの機器は承認後も監視専用で、遠隔操作には署名とローカル権限が必要です。承認ボタンは全機器にrootターミナルを開放しません。

承認しても即座にオンラインにならない理由

v0.3.0では承認待ちのエージェントは約1分間隔で再試行します。承認後、通常は次の接続で正式なセッションを開始し、上報へ進みます。古い接続が直ちに切り替わる方式ではありません。

数秒後にデータがなくても、削除や再インストールの前にログを見ます。ただし1分は稼働保証ではありません。DNSや通信、鍵の不一致があれば次の試行も失敗します。待機中なのか、試行して失敗したのかを区別してください。

通常の切断には別の再試行方針がある

ネットワークエラー後は指数バックオフにランダムな揺らぎを加えます。サーバー復旧時に全エージェントが同時接続するのを緩和するためです。

待ち時間の基数は1秒から60秒まで増えますが、実際には乱数分が上乗せされます。「必ず60秒以内に再接続」とは言えません。前のセッションが1分を超えて続いた場合、切断時に基数を短く戻します。

サーバーは保活メッセージも送り、受信が長時間進まなければセッションを終了して再接続へ移ります。これは通信の復旧であって、操作の再開保証ではありません。

オンラインに戻っても、前のコマンドが成功したとは限らず、ターミナルの作業が継続するとも限りません。 更新、ネットワーク変更、サービス再起動はそれ自体が通信を切る場合があります。完了表示がないからと同じ操作を繰り返す前に、実際の結果を確認します。

タスクの寿命は後の記事で扱います。ここでは接続復旧と作業復旧を分けて理解します。

改名、アドレス変更、再インストールを区別する

識別は鍵に基づき、ホスト名やIPとは別です。同じ鍵で新しいアドレスから戻る場合と、新しい鍵で登録し直す場合では意味が違います。

再インストールで元の鍵を消すと、同名でも新規機器になり得ます。逆に登録済みシステムを複製すると、別機器へ同じ鍵をコピーしてしまうことがあります。

同じ識別情報の2台を独立機器として扱うことはできません。現在のサーバーは同一登録機器の新接続を受けると旧接続を取り消すため、切断の繰り返しに見える場合もあります。

システムテンプレートに登録済みの秘密鍵を含めないでください。通常の再起動では識別を保持し、新規機器には個別の鍵を作る。この2つを同じディレクトリ丸ごとコピーで済ませるべきではありません。

削除しても、再び申請してくることがある

管理画面で削除すると記録と履歴が消えますが、エージェントが動き続ければ承認待ちとして戻れます。サーバーは承認を忘れても、機器は接続をやめていないためです。

表示名の変更は改名を使います。管理をやめるなら停止・アンインストールし、識別情報を拒否するなら拒否機能を使います。拒否した公開鍵は解除するまで受け入れを阻止されます。

拒否対象は鍵です。鍵を生成し直せば別の識別となり、再び承認が必要です。物理機器を永続的に禁止する機能ではありません。

現在の承認待ち上限は50台です。登録キューの境界であり、包括的な攻撃対策ではありません。公開範囲、入口の保護、管理者アカウントも適切に管理します。

どの段階で止まったかを調べる

状況	最初に確認すること
サービスが起動しない	アーキテクチャ、取得・導入エラー、systemd/procd
承認待ちに出ない	接続先、DNS、送信経路、WebSocket、サーバー鍵
承認待ちでグラフがない	指紋確認、承認、次回の試行時刻
承認後もオフライン	直近のハンドシェイクと正式セッションへの移行
オンラインだが操作拒否	ローカル権限、署名鍵、対象、有効期限
削除後に戻る	エージェントが動作中か、停止・拒否が必要か

systemdの機器では次を確認します。

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 80 --no-pager

OpenWrt / iStoreOSでは対応するサービスとログを使います。

/etc/init.d/fleetd-agent status
logread | grep fleetd

出力はシステム版で異なります。公開相談時は実際のドメイン、アドレス、機密情報を除去し、秘密鍵は送らないでください。

最初の目標は小さくてよい

テスト機1台をmonitorで起動し、信頼する経路で指紋を照合し、承認後に新しいデータが届くことを確認します。その後、計画したエージェント再起動で同じ識別のまま戻るかを見ます。

いきなり全機器をfullにして一括操作するより、接続の問題を理解しやすくなります。到達性、サーバーの身元、機器の身元、実行できる操作を分けることが、診断と認可の土台です。

次回は、サーバーを通った要求をなぜエージェントでも署名検証するのか、その前提と限界を説明します。