ネットワーキングとディスカバリー

ディスカバリーとトランスポート

OpenClawには、表面上似ているが異なる2つの問題があります：

設計目標は、すべてのネットワークディスカバリー/アドバタイズをノードゲートウェイ (openclaw gateway) 内に保持し、クライアント（macアプリ、iOS）を消費者として保つことです。

用語

ゲートウェイ: 状態（セッション、ペアリング、ノードレジストリ）を所有し、チャネルを実行する単一の長時間実行ゲートウェイプロセス。ほとんどのセットアップではホストごとに1つ使用します。分離されたマルチゲートウェイセットアップも可能です。
ゲートウェイWS（コントロールプレーン）: デフォルトで 127.0.0.1:18789 にあるWebSocketエンドポイント。gateway.bind を介してLAN/tailnetにバインド可能。
ダイレクトWSトランスポート: LAN/tailnet向けのゲートウェイWSエンドポイント（SSHなし）。
SSHトランスポート（フォールバック）: SSH経由で 127.0.0.1:18789 をフォワーディングするリモート制御。
レガシーTCPブリッジ（非推奨/削除済み）: 古いノードトランスポート（ブリッジプロトコルを参照）。ディスカバリー用にはアドバタイズされなくなりました。

プロトコルの詳細：

ダイレクトWSは、同じネットワーク内およびtailnet内で最高のユーザーエクスペリエンスを提供します：
- BonjourによるLAN上の自動ディスカバリー
- ペアリングトークン + ACLはゲートウェイが所有
- シェルアクセス不要。プロトコルサーフェスは厳密で監査可能なままに保てる
SSHは普遍的なフォールバックとして残ります：
- SSHアクセスがあればどこでも動作（無関係なネットワーク間でも）
- マルチキャスト/mDNSの問題を乗り越える
- SSH以外の新しいインバウンドポートを必要としない

Bonjourはベストエフォートであり、ネットワークを越えません。「同じLAN」内での利便性のためにのみ使用されます。目標の方向性：

トラブルシューティングとビーコン詳細：Bonjour。

セキュリティ上の注意：

Bonjour/mDNS TXTレコードは認証されていません。クライアントはTXT値をUXのヒントとしてのみ扱う必要があります。
ルーティング（ホスト/ポート）は、TXTで提供される lanHost、tailnetDns、gatewayPort よりも、解決されたサービスエンドポイント (SRV + A/AAAA) を優先する必要があります。
TLSピニングは、アドバタイズされた gatewayTlsSha256 が以前に保存されたピンを上書きすることを決して許可してはいけません。
iOS/Androidノードは、ディスカバリーベースのダイレクト接続をTLSのみとして扱い、初回のピンを保存する前に明示的な「このフィンガープリントを信頼する」確認を要求する必要があります（アウトオブバンド検証）。

無効化/上書き：

London/Viennaスタイルのセットアップでは、Bonjourは役に立ちません。推奨される「ダイレクト」ターゲットは：

ゲートウェイがTailscale下で動作していることを検出できる場合、クライアント（広域ビーコンを含む）向けのオプションのヒントとして tailnetDns を公開します。

ダイレクトルートがない（またはダイレクトが無効になっている）場合、クライアントは常にSSH経由でループバックゲートウェイポートをフォワーディングすることで接続できます。リモートアクセスを参照してください。

推奨されるクライアントの動作：

ペアリング済みのダイレクトエンドポイントが設定されており到達可能な場合は、それを使用する。
そうでなく、BonjourがLAN上でゲートウェイを見つけた場合、ワンタップの「このゲートウェイを使用する」選択肢を提供し、それをダイレクトエンドポイントとして保存する。
そうでなく、tailnet DNS/IPが設定されている場合、ダイレクトを試みる。
それ以外の場合は、SSHにフォールバックする。

ゲートウェイは、ノード/クライアントの許可に関する信頼できる情報源です。

ペアリングリクエストはゲートウェイ内で作成/承認/拒否されます（ゲートウェイペアリングを参照）。
ゲートウェイは以下を強制します：
- 認証（トークン / キーペア）
- スコープ/ACL（ゲートウェイはすべてのメソッドへの生のプロキシではありません）
- レート制限