Gateway
検出とトランスポート
OpenClaw には、関連しているものの異なる 2 つの検出上の問題があります。
- オペレーターによるリモート制御: 別の場所で稼働している Gateway を macOS メニューバーアプリから制御します。
- Node のペアリング: iOS/Android(および将来の Node)が Gateway を検出し、安全にペアリングします。
ネットワーク上の検出とアドバタイズはすべて Node Gateway
(openclaw gateway)が担い、クライアント(Mac アプリ、iOS)は利用するだけです。
用語
- Gateway: 状態(セッション、ペアリング、Node レジストリ)を所有し、チャンネルを実行する単一の長時間稼働プロセスです。ほとんどの構成ではホストごとに 1 つ使用しますが、分離された複数 Gateway 構成も可能です。
- Gateway WS(コントロールプレーン): デフォルトでは
127.0.0.1:18789上の WebSocket エンドポイントです。gateway.bindを使用して LAN/tailnet にバインドします。 - 直接 WS トランスポート: LAN/tailnet 向けの Gateway WS エンドポイントです(SSH は使用しません)。
- SSH トランスポート(フォールバック): SSH 経由で
127.0.0.1:18789を転送してリモート制御します。 - 従来の TCP ブリッジ(削除済み): 以前の Node トランスポートです(ブリッジプロトコルを参照)。検出用にアドバタイズされなくなり、現在のビルドにも含まれていません。
プロトコルの詳細: Gateway プロトコル、 ブリッジプロトコル(従来版)。
直接接続と SSH の両方が存在する理由
- 直接 WS は、同じネットワーク上および tailnet 内で最良のユーザー体験を提供します。Bonjour による LAN 自動検出、Gateway が管理するペアリングトークンと ACL を利用でき、シェルアクセスも必要ありません。
- SSH は汎用的なフォールバックです。SSH アクセスさえあれば無関係なネットワーク間でも利用でき、マルチキャスト/mDNS の問題の影響を受けにくく、SSH 以外の新しい受信ポートも必要ありません。
検出情報源
1) Bonjour / DNS-SD
マルチキャスト Bonjour はベストエフォートであり、ネットワークを越えて動作しません。OpenClaw は、設定された広域 DNS-SD ドメインを介して同じ Gateway ビーコンを参照することにも対応しているため、同じ LAN 上の local. と、ネットワークを越えた検出用に設定されたユニキャスト DNS-SD ドメインの両方を検出対象にできます。
バンドルされた bonjour Plugin が有効な場合、Gateway は Bonjour 経由で WS エンドポイントをアドバタイズします。クライアントはそれを参照して「Gateway を選択」リストを表示し、選択されたエンドポイントを保存します。
トラブルシューティングとビーコンの詳細: Bonjour。
サービスビーコンの詳細
-
サービスタイプ:
_openclaw-gw._tcp(Gateway トランスポートビーコン)。 -
TXT キー(機密情報ではありません):
キー 注記 role=gateway常に存在します。 transport=gateway常に存在します。 displayName=<name>オペレーターが設定した表示名。 lanHost=<hostname>.localLAN mDNS アドバタイザーのみ。広域 DNS-SD では書き込まれません。 gatewayPort=18789Gateway WS + HTTP ポート。 gatewayTls=1TLS が有効な場合のみ。 gatewayTlsSha256=<sha256>TLS が有効で、フィンガープリントを利用できる場合のみ。 tailnetDns=<magicdns>任意のヒント。Tailscale が利用可能な場合は自動検出されます。 sshPort=<port>discovery.mdns.mode="full"の場合のみ存在します。デフォルトの"minimal"モードでは省略され(SSH のデフォルトは22)、LAN アドバタイザーと広域 DNS-SD の両方で同様です。cliPath=<path>sshPortと同じdiscovery.mdns.mode="full"ゲート。CLI パスに関するリモートインストール用のヒントです。将来のキャンバスホストポート用として、Plugin 検出コントラクトには
canvasPortTXT キーが定義されていますが、現在は値を設定するコードパスがないため、現時点では出力されません。
セキュリティ上の注意:
- Bonjour/mDNS TXT レコードは認証されていません。クライアントは TXT 値をユーザー体験上のヒントとしてのみ扱う必要があります。
- ルーティング(ホスト/ポート)では、TXT が提供する
lanHost、tailnetDns、gatewayPortよりも、解決済みのサービスエンドポイント(SRV + A/AAAA)を優先する必要があります。 - TLS ピンニングでは、アドバタイズされた
gatewayTlsSha256によって、以前に保存されたピンが上書きされることがあってはなりません。 - 選択した経路が安全な TLS ベースである場合、iOS/Android Node は初回のピンを保存する前に、明示的な「このフィンガープリントを信頼する」という確認(帯域外検証)を必須にする必要があります。
有効化、無効化、上書き:
openclaw plugins enable bonjourは LAN マルチキャストアドバタイズを有効にします。openclaw.json内のdiscovery.mdns.modeは mDNS ブロードキャストを制御します。"minimal"(デフォルト)、"full"(LAN ビーコンとすべての広域 DNS-SD ゾーンの両方にcliPath/sshPortを追加)、または"off"(mDNS を無効化)を指定できます。OPENCLAW_DISABLE_BONJOUR=1はアドバタイズを強制的に無効にし、discovery.mdns.mode="off"はそれとは独立して無効にします。OPENCLAW_DISABLE_BONJOUR=0は、検出されたコンテナ(Docker、containerd、Kubernetes、LXC)内での Plugin の自動無効化を上書きする明示的なオプトインです。ただし、discovery.mdns.mode="off"は上書きしません。バンドルされたbonjourPlugin は macOS ホスト(enabledByDefaultOnPlatforms: ["darwin"])では自動起動し、検出されたコンテナ内では自動的に無効になります。Linux、Windows、およびその他のコンテナ化されたデプロイでは、明示的なplugins enable bonjourが必要です。~/.openclaw/openclaw.json内のgateway.bindは Gateway のバインドモードを制御します。OPENCLAW_SSH_PORTは、アドバタイズされる SSH ポートを上書きします(discovery.mdns.mode="full"の場合のみ有効です)。OPENCLAW_TAILNET_DNSはtailnetDnsヒント(MagicDNS)を公開します。OPENCLAW_CLI_PATHは、アドバタイズされる CLI パスを上書きします。
2) Tailnet(ネットワーク間)
異なる物理ネットワーク上にある Gateway の検出には、Bonjour は役立ちません。直接接続先として推奨されるのは、Tailscale MagicDNS 名(推奨)または安定した tailnet IP です。
Gateway が Tailscale 環境で稼働していることを検出すると、クライアント向けの任意のヒントとして tailnetDns を公開します(広域ビーコンを含む)。macOS アプリは Gateway の検出時に、生の Tailscale IP よりも MagicDNS 名を優先します。MagicDNS は現在の IP を自動的に解決するため、tailnet IP が変更された場合(Node の再起動、CGNAT の再割り当て)でも信頼性を維持できます。
モバイル Node のペアリングでは、検出ヒントによって tailnet/パブリック経路上のトランスポートセキュリティ要件が緩和されることはありません。
- iOS/Android では、初回の tailnet/パブリック接続時に安全な接続経路(
wss://または Tailscale Serve/Funnel)が引き続き必要です。 - 検出された生の tailnet IP はルーティングのヒントであり、平文のリモート
ws://の使用を許可するものではありません。 - プライベート LAN への直接接続
ws://は引き続きサポートされます。 - モバイル Node で最も簡単に Tailscale を利用するには、Tailscale Serve を使用し、検出とセットアップの両方が同じ安全な MagicDNS エンドポイントを解決するようにします。
3) 手動 / SSH 接続先
直接経路がない場合(または直接接続が無効な場合)、クライアントは loopback Gateway ポートを転送することで、いつでも SSH 経由で接続できます。リモートアクセスを参照してください。
トランスポートの選択(クライアントポリシー)
- ペアリング済みの直接エンドポイントが設定され、到達可能な場合は、それを使用します。
- それ以外の場合、検出によって
local.または設定された広域ドメイン上で Gateway が見つかった場合は、ワンタップの「この Gateway を使用」選択肢を提示し、直接エンドポイントとして保存します。 - それ以外の場合、tailnet DNS/IP が設定されていれば直接接続を試みます。tailnet/パブリック経路上のモバイル Node では、直接接続とは安全なエンドポイントを意味し、平文のリモート
ws://を意味しません。 - それ以外の場合は、SSH にフォールバックします。
ペアリングと認証(直接トランスポート)
Gateway は Node/クライアントの受け入れに関する信頼できる唯一の情報源です。
- ペアリング要求は Gateway 内で作成、承認、拒否されます(Gateway のペアリングを参照)。
- Gateway は認証(トークン/キーペア)、スコープ/ACL(すべてのメソッドに対する単なる生のプロキシではありません)、およびレート制限を適用します。
コンポーネント別の責務
- Gateway: 検出ビーコンをアドバタイズし、ペアリングの判断を管理し、WS エンドポイントをホストします。
- macOS アプリ: Gateway の選択を支援し、ペアリングプロンプトを表示し、フォールバックとしてのみ SSH を使用します。
- iOS/Android Node: 利便性のために Bonjour を参照し、ペアリング済みの Gateway WS に接続します。