RustDeskがDirect接続かRelay接続か確認する方法

自前のRustDeskサーバー（hbbs / hbbr）を構築して使っていると、「本当にP2P直結（Direct）できているのか？それともリレー（Relay）経由になっているのか？」が気になります。Direct接続なら高速ですが、Relay経由だとサーバーを中継するぶん遅くなるためです。

この記事では、RustDeskの接続がDirectかRelayかを、サーバー側のログから確実に判定する方法を解説します。クライアントのUI表示よりも、サーバーログのほうが確実に判断できます。

前提：RustDeskサーバーの2つの役割

まず仕組みを押さえておきます。自前サーバーは2つのコンポーネントから成ります。

  • hbbs（ID/Rendezvousサーバー）… 端末の登録、相手探し、NAT越えの仲介（ホールパンチング）を担当
  • hbbr（Relayサーバー）… NAT越えに失敗したときだけ、通信を中継

NAT越えに成功すれば、映像や操作のデータは端末同士を直接流れ、hbbrは一切関与しません。直結できなかったときだけhbbr経由のリレーになります。

ここがポイントです。hbbrのログにアクセス記録があればRelay、無ければDirect、というのが基本的な判定原理です。

判定方法1：hbbrのログを見る（最も確実）

サーバーにSSHでログインし、hbbrのログをリアルタイムで監視します。

docker logs hbbr -f

この状態で、クライアントから実際に接続・操作してみます。

Directの場合

hbbrには起動時のログ以外、何も流れません。例えば次のような起動ログだけで止まっていれば、hbbrは使われていない＝Direct接続です。

INFO [src/relay_server.rs:82] Listening on tcp :21117
INFO [src/relay_server.rs:84] Listening on websocket :21119
INFO [src/relay_server.rs:87] Start

Relayの場合

hbbrが実際に中継すると、次のようなログが流れます。

INFO [src/relay_server.rs:453] New relay request xxxx from [::ffff:203.0.113.10]:56757
INFO [src/relay_server.rs:437] Relay request xxxx from [::ffff:198.51.100.20]:44895 got paired
INFO [src/relay_server.rs:443] Both are raw
...
INFO [src/relay_server.rs:449] Relay of [::ffff:198.51.100.20]:44895 closed

New relay request（リレー要求）→ got paired（2つの接続がペアリング）→ closed（終了）という一連の流れが出ていれば、確定でRelay経由です。このとき、ペアになっている2つのIPアドレスが、接続している2台の端末のグローバルIPです。

判定方法2：hbbrを止めてみる（白黒つけたいとき）

「ログが増えないのは正常なのか、異常なのか分からない」というときは、hbbrを実際に止めてしまうのが一番はっきりします。

docker stop hbbr

この状態で、接続を一度切ってから新しく繋ぎ直してみます（既存の接続はそのままだと判定できないので、必ず再接続します）。

  • 繋ぎ直せる → Direct接続。hbbrは元から不要だったので、止めても影響がない
  • 繋ぎ直せない → 本来Relayが必要な環境だった

テストが終わったら必ず戻します。

docker start hbbr

hbbsのログについての注意

「hbbsのログを見ればいいのでは？」と思うかもしれませんが、hbbsのログだけではDirect/Relayの判定はできません。

hbbsに出る代表的なログはこれです。

INFO [src/peer.rs:102] update_pk 216809016 [::ffff:203.0.113.10]:50780 ...

update_pk はクライアントがサーバーにIDと公開鍵を登録したときのログであり、「今まさに2台が接続した」というイベントを示すものではありません。接続を繰り返しても、すでに登録済みのクライアントは再登録しないため、update_pk は増えません。これは正常な挙動で、hbbsのログが増えないこと自体は問題ではありません。

また、次のようなログが出ることもあります。

INFO [src/rendezvous_server.rs:605] IP change of 1256059016 from [::ffff:203.0.113.10]:54212 to [::ffff:198.51.100.20]:61180

これは、その端末がネットワークを切り替えた（Wi-Fiからモバイル回線へ、など）ことでアクセス元IPが変わり、サーバー側の登録情報を更新した、という意味です。pk updated instead of insert が続いていれば、「新規登録ではなく既存情報の更新」を示しています。

サーバー設定の確認：ALWAYS_USE_RELAY

hbbsの起動ログに、次の行があります。

INFO [src/rendezvous_server.rs:161] ALWAYS_USE_RELAY=N

これは「常にリレーを使うモード」の設定値です。

  • N（デフォルト）… まずP2P直結を試み、失敗したときだけRelayにフォールバック
  • Y … P2P直結を試みず、毎回必ずRelay経由にする

ALWAYS_USE_RELAY=N であれば、サーバー側は「直結優先」になっています。それでもRelayになる場合、原因はサーバー設定ではなく、クライアント側のネットワーク環境でNAT越えが失敗していることに絞られます。

Relayになってしまう主な原因

ALWAYS_USE_RELAY=N なのにRelayになる場合、クライアント側に次のような要因があります。

  • CGNAT配下（モバイル回線、povo2.0などのSIM、テザリング）… 複数ユーザーでIPを共有するため、ホールパンチングが成立しにくい
  • 対称型NAT（Symmetric NAT）を使う家庭用ルーター
  • ファイアウォールでUDPがブロックされている

接続する2台のうち、少なくとも一方がこうした環境にいると、NAT越えに失敗してRelayにフォールバックします。

接続元のグローバルIPがどの回線か調べるには、WHOIS検索サービス（ipinfo.io など）でIPを引いてみると、プロバイダ名（モバイル系か固定回線か）が分かります。モバイル系であればCGNATがほぼ確実に原因です。

まとめ

  • DirectかRelayかは、hbbrのログにアクセス記録があるかどうかで判定するのが最も確実
  • hbbrを一時的に止めて繋ぎ直すテストが、白黒つけるのに有効
  • hbbsの update_pk が増えないのは正常。hbbsログだけでは判定できない
  • ALWAYS_USE_RELAY=N でもRelayになるなら、原因はクライアント側のNAT環境（CGNATなど）

自前サーバーでDirect接続が安定して成立していれば、サーバーは最初のお見合いだけで関与せず、端末間で直接・高速に通信できている状態です。Relayが多い場合は、クライアント側のネットワーク環境を見直すのが解決の糸口になります。

コメント