他のプレイヤーのトンネルアドレスに ping を送ることと、そのプレイヤーがホストするゲームが見えることは別の成果です。ロビーの一覧は通常、単一のローカルネットワーク向けに書かれた検出のやり取りに依存しており、ゲームセッション自体はアドレスとポートへの普通の接続です。空の一覧をルーティング障害とみなすと、必要のないブリッジへ向かうことになるので、何かを変える前に二つの問いを切り分けてください。

セッションへの参加と、セッションの発見を切り分ける

参加の失敗はルート、ファイアウォール規則、待ち受けサービスを示します。一覧が空のまま参加に成功した場合は、検出か、告知が運ぶアドレスを示します。この二つの結果はまったく別の作業に導くもので、一つ目を意識的に試さなければ区別できません。

VPN の設定に触れる前に結果を書き留めてください。これは調査全体で最も安い試験であり、設計空間の半分を消します。使ったアドレスも記録してください。後のすべての試験の基準点になるからです。ノートにその一行がなければ、次の比較は推測にすぎません。

トンネルに触れる前に直接参加を試す

ゲームに直接接続のオプションがあるなら、ホストのトンネルアドレスと文書化されたゲームのポートを使い、ゲーム自身の認証とホストのファイアウォール規則はそのままにします。参加に成功すれば問題は検出に絞られます。失敗した場合は別の調査が必要で、中継では直りません。

検出ポートとセッションポートが同じ番号だと考えないでください。ゲームは通常、一方の UDP ポートで告知し、もう一方でプレイヤーを受け入れます。間違った側向けに作られた中継は、やはり空の一覧を生みます。

ホスト側のプロセスがどのアダプターを選んだかも確認してください。家庭内 LAN のアドレスに束縛されたプロセスはそのアドレスを告知し、告知が届いても遠隔のプレイヤーはそこへ経路を張れません。一覧が埋まっても、それだけで参加は失敗し得ます。

ブロードキャストがどこで止まるかを理解する

ルーティングされた TUN トンネルはピア間で IP パケットを運び、各ピアのネットワークでローカルブロードキャストを再現しません。限定ブロードキャストアドレス 255.255.255.255 はそれを送出するインターフェースの内側にとどまり、サブネット宛てのブロードキャストは別のケースであって、ルーターが告知を氾濫させる一般的な許可ではありません。

これは設計の性質であり、オプションで埋めるべき欠陥ではありません。OpenVPNのclient-to-client設定がトンネル内のピア間トラフィックを制御しており、検出の中継ではありません。多くのスレッドでこの目的に勧められていますが、中継は独自の設定と独自の故障モードを持つ別個のコンポーネントです。既存のオプションがすでにそれを覆っていると仮定することが、この調査が行き詰まる最も一般的な道です。

マルチキャスト検出も別のアドレスクラスで同じ問題を抱え、ブロードキャストの例外ではなくマルチキャストルーティングか中継を必要とします。

中継が正当化される場合は、範囲を狭く保つ

自動検出が要件なら、まず実際のやり取りを特定します。ブロードキャストかマルチキャストか、宛先アドレス、UDP ポート、送出するインターフェース、応答の内側のアドレスです。この五つの事実に限定したプロトコルに適した中継は、Ethernet セグメント全体を拡張するよりはるかに狭いものです。

パケットをそのまま転送しても足りないことがあります。ペイロードが受信側に到達できないアドレスへ接続するよう指示しているなら、中継は無意味な応答を届けます。だからこそ中継が存在する前に、ゲーム自身のインターフェースや告知アドレスの設定を試すべきです。

中継は必要とするインターフェースとピアに限定し、応答が要求元をどう見つけるかを定義してください。無関係なブロードキャストを繰り返すと、他のローカルサービスが露出し、後でデバッグが苦痛なループを作ります。

設計が Ethernet を必要とするときだけブリッジする

Ethernet フレームは TAP の内側を流れるため、TAP トンネルは意図的にブリッジされたブロードキャストドメインに属せます。単に dev tun を dev tap に切り替えても、そのブリッジは築かれず、サーバー設定が互換になるわけでも、アプリケーションが新しいインターフェースを選ぶわけでもありません。OpenVPN のブリッジングガイドは、一つの空のロビーへの治療ではなく、より広い構成を説明しています。

ブリッジはアドレス計画も平坦にします。だからこそこの判断は、せっかちさ以外の理由を持つに値します。別々だった二つのネットワークが一つになり、どちらの側のサービスも相手側のブロードキャストを見始めます。その帰結は、誰かが有効にする前に変更記録に書かれるべきものです。ゲームクライアントが 192.168 の範囲にいなければならないという規則はありません。重複しない計画を選び、フォーラムの投稿がそうしたからという理由でトンネルを採番し直すのではなく、個々のゲームの制約を確認してください。

最後に二つの結果を分けてください。ホストに参加できるかということと、検出の応答が他のプレイヤーが実際に使える宛先を告知しているかということです。一つ目を確認せずに二つ目を直すのが、ブロードキャストとは無関係な問題のためにブリッジを維持し続ける道です。

関連記事