イスラエルおよび中東の一部の国で発生した主要なP2P問題

 (github.com/ValveSoftware)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 現在のステータスは Open であり、ValveSoftware のメンバーは、SDR を使用するパートナーとともに "Share IP Address" が守られない理由を調査するため、この事例を活用できるとの立場
  • 2026年3月13日ごろから Steam Networking を使う P2P ゲームで問題が発生しており、Street Fighter 6 のイスラエルでの PC-to-PC 対戦は約 120ms、ヨーロッパのプレイヤーとの対戦は 60〜80ms、PC-to-PS5 対戦は 5〜10ms だったという報告
  • イスラエルのコミュニティの数十人が複数の ISP で同じ問題を経験しており、ISP への問い合わせやポートフォワーディング後もネットワーク上の問題は見つからず、Steam Networking を使わない Tekken 8 では問題がなかったという報告
  • 中国のプレイヤーも Warhammer: Vermintide 2 で、両者が "Share IP Address" を有効にしていても直接の P2P 接続 が成立せず、すべてのプレイヤーデータが Steam の SDR リレーを経由して遅延が急増したと報告
  • SDR サーバートラフィックを遮断して直接 P2P 接続を強制しようとすると、オンラインマッチが開始されないという追加の再現例
  • steamwebrtc64.dll を Steam のインストールディレクトリからゲームフォルダ内の Binaries、Binaries/Win64、Binaries_dx12 のいずれかにコピーし、両方のプレイヤーが適用すると "NAT traversal successful, IP shared" と表示され、P2P 接続が復旧するという暫定的な回避策
  • この回避策は Deep Rock Galactic、Warhammer: Vermintide 2、Far Far West で動作確認済みとして共有されており、Street Fighter 6 と Melty Blood でも適用事例が追加
  • Melty Blood では steam_api.dll を使用しているため steamwebrtc64.dll ではなく steamwebrtc.dll を使う必要があり、Binaries フォルダがない場合は steam_api64.dll と同じフォルダに配置したという適用記録
  • あるユーザーは、旧 Steam クライアントは STUN によって直接 P2P を設定するが、新しいクライアントは何らかの理由でそれを試みていないと整理しており、正確な変更点は不明なまま

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • ここではValveが壊したというより、中東紛争がサイバー空間に拡大し、その影響が一般ユーザーにまで及んだように見える
    タイミングや影響を受けた国々を見るとそう思えるし、中国も自由なインターネットで有名な場所ではない
    WebRTCは代替経路として動作し、暗号化されていて、別の用途に悪用するのも難しい
    一方でSTUNは暗号化されておらず、プロトコル自体がDDoS反射/増幅に使えるため、武器化されたか、リアルタイム遮断・分析の過程で接続性が壊れたとしても不思議ではない

    • STUN/TURNはWebRTCにおいてほぼicanhazipのような役割
      STUNは公開IP:ポートを知らせ、TURNも似ているが、実アドレスではなく問い合わせ時点で動的に割り当てられたIP:ポートを返す
      WebRTCクライアントはそのSTUN/TURN応答を、ロビーサーバーのチャットのような帯域外シグナリング経路でピアに送り、接続を確立し、両側のNATテーブルにあたかも外向き接続であるかのような項目を作れるようにする
      STUN/TURNだけではP2P接続は作れず、WebRTCに必要な道具にすぎない
    • WebRTC上でWireGuardに似たP2P VPNを作ってみたが、性能は300Mbps超と良好だった
      エンドユーザーがファイアウォールの問題やIPv4/IPv6の違いを気にしなくてよいので、IPベースの解決策の代わりに、リアルタイムP2Pゲームや企業ネットワーキング向けにWebRTCを適用できると思う
    • 逆に理解しているようだ。WebRTCがダメで、STUNは動く
    • うちのネットワーキングソフトウェアもP2Pを使うが、そのためSTUNやTURNのような一般的な方式ではなく、すべてインバンド処理で実装している
      ああした方式は遮断されることもあるし、セキュリティも脆弱な場合が多い
      STUNには今では武器化への緩和策があるが、それでもなおひどいプロトコルで、STUNにもTURNにも、別個のシグナリング経路なしにランデブーを行う方法がまったくないのが理解できない。簡単に入れられたはずなのに
    • IPv6と、ニッチで複雑な機能なしのアセンブリで最小実装したネットワークコードで十分

  • もう皆が知っている話だろうが、オープンソースやソース公開ライブラリ・アプリケーションの一番よい点は、こうしたバグレポートやPR議論だ
    いろいろな人がそれぞれの症状、回避策、原因仮説を持ち寄っていく様子は本当に心温まる

    • GitHubの議論も、プラットフォームが専門家中心だった頃のほうがずっと質が高かった
      最近は多くの議論が事実上reddit/4chanのスレッドのように流れていくのをよく見るので、離れる理由がまたひとつ増えた

  • タイトルがGitHub Issueの元タイトルである「Major P2P issues in Israel and possibly other middle east countries」と一致していない

  • HNらしい荒っぽい推測ではあるが、GitHub Issueを最後まで読むと、ユーザーはSTUN失敗を報告している
    つまりP2Pリンクが確立されず、遅延の大きいリレーサーバーに置き換わっている状況だ
    複数のユーザーは古いValve WebRTC dllに手動で差し替えて問題を回避しており、Valve開発者の事後分析を読んでみたい

  • タイトルから「in Israel and possibly other middle east countries」の部分をなぜ外したのか？ クリック誘導か？

    • あるいは、世の中にはすでに十分すぎるほどイスラエル/パレスチナ論争のスレッドがあり、さらにもうひとつの炎上案件に広がるのを避けたかったのかもしれない
    • ここに長くいれば、その文句まで入れるとタイトル文字数制限を超えるとわかるはずだ

  • 本当に気の抜けた投稿で、これほど推薦を集めたのが信じられない
    皆がタイトルのValveだけを見て重要だと思ったのだろうが、実際のIssue内容はタイトルとも一致していない

  • 当初はイスラエルと中東の一部の国における大きなP2P問題として始まったが、追加調査の結果、世界的な問題のように見えてきた

    • これまでのところ「世界的」とは、イスラエル、ロシア、中国あたりを意味する
      いずれもインターネットの自由を特に好まず、監視と検閲の長い歴史を持つ国々なので、検閲ISPの回避を難しくするためのP2Pネットワーク政策の副作用かもしれない

  • これはValveの問題ではないように見える
    報告されている問題は、接続を非常に攻撃的にスキャンしてフィルタリングする国々でのみ起きているようで、P2Pはこうした介入に敏感だ
    SDRは暗号化されたリレーネットワークで、オニオンルーティングのようなものに近い
    悪意ある行為者がP2Pゲームを配布し、そのゲーム経由でSDR上の通信を流せることはよく知られている
    こうした地域でそのトラフィックを検査したがるだろうことは容易に想像できる

  • 中国にいるが、3週間ほど前にSteamのSpacewar開発者向けゲームを通じてサードパーティ製ゲームを遊び、おそらくSteam P2Pが有効だったが問題なく動作した

  • タイトルだけ見ると、どこでも壊れているように見える