Problème P2P majeur survenu en Israël et dans certains pays du Moyen-Orient

• L’état actuel est Open, et les membres de ValveSoftware indiquent que ce cas peut servir à enquêter, avec les partenaires utilisant SDR, sur la raison pour laquelle "Share IP Address" n’est pas respecté
• Des problèmes sont apparus à partir du 13 mars 2026 environ dans les jeux P2P utilisant Steam Networking, avec des signalements indiquant que les matchs PC-à-PC de Street Fighter 6 en Israël affichaient environ 120 ms, les matchs contre des joueurs européens 60 à 80 ms, et les matchs PC-vers-PS5 5 à 10 ms
• Des dizaines de membres de la communauté israélienne ont signalé le même problème chez plusieurs FAI, et, même après avoir contacté leur FAI et configuré le port forwarding, ils n’ont trouvé aucun problème réseau ; Tekken 8, qui n’utilise pas Steam Networking, ne présentait pas ce souci
• Des joueurs chinois ont aussi signalé que dans Warhammer: Vermintide 2, même lorsque les deux côtés activaient "Share IP Address", une connexion P2P directe ne s’établissait pas, et que toutes les données des joueurs passaient par le relais SDR de Steam, entraînant une forte hausse de la latence
• Reproduction supplémentaire : si l’on bloque le trafic vers les serveurs SDR pour forcer une connexion P2P directe, le match en ligne ne démarre pas
• Solution de contournement temporaire : copier steamwebrtc64.dll depuis le répertoire d’installation de Steam vers l’un des dossiers Binaries, Binaries/Win64 ou Binaries_dx12 du jeu ; si les deux joueurs l’appliquent, "NAT traversal successful, IP shared" s’affiche et la connexion P2P est rétablie
• Cette solution de contournement a été partagée comme fonctionnelle pour Deep Rock Galactic, Warhammer: Vermintide 2 et Far Far West, avec des cas d’application supplémentaires rapportés pour Street Fighter 6 et Melty Blood
• Dans Melty Blood, comme steam_api.dll est utilisé, il fallait employer steamwebrtc.dll au lieu de steamwebrtc64.dll ; lorsqu’il n’y avait pas de dossier Binaries, le fichier a été placé dans le même dossier que steam_api64.dll
• Un utilisateur a résumé que l’ancien client Steam configurait une connexion P2P directe via STUN, alors que le nouveau client ne semble pas tenter de le faire pour une raison inconnue ; l’état exact du changement reste non identifié

[GN⁺]

Commentaires Hacker News

• Ici, il semble moins que Valve ait cassé quelque chose que que le conflit au Moyen-Orient se soit étendu au cyberespace, avec des effets qui ont touché jusqu’aux utilisateurs civils
  Le moment et les pays affectés vont dans ce sens, et la Chine n’est pas non plus réputée pour son internet libre
  WebRTC fonctionne comme une voie alternative, il est chiffré, et il est aussi difficile de le détourner à d’autres usages
  En revanche, STUN n’est pas chiffré, et le protocole lui-même peut servir à la réflexion/amplification DDoS, donc il ne serait pas surprenant qu’il ait été militarisé, ou que la connectivité ait été cassée pendant un blocage ou une analyse en temps réel

  • En WebRTC, STUN/TURN joue presque le rôle de icanhazip
    STUN fournit l’IP:port publique, et TURN est similaire, mais renvoie une IP:port allouée dynamiquement au moment de la requête plutôt que l’adresse réelle
    Les clients WebRTC envoient ensuite cette réponse STUN/TURN au pair via une voie de signalisation hors bande, comme le chat d’un serveur de lobby, afin d’établir la connexion et de pouvoir créer dans les tables NAT des deux côtés des entrées qui ressemblent à des connexions sortantes
    STUN/TURN seul ne permet pas de créer une connexion P2P ; ce n’est qu’un outil nécessaire à WebRTC
  • J’ai déjà créé un VPN P2P de type WireGuard au-dessus de WebRTC, et les performances étaient bonnes, au-delà de 300 Mbps
    Comme l’utilisateur final n’a pas à se soucier des problèmes de pare-feu ni des différences IPv4/IPv6, je pense qu’on peut adapter WebRTC à des usages comme les jeux P2P en temps réel ou le networking d’entreprise plutôt que d’utiliser des solutions basées sur l’IP
  • Je crois que c’est l’inverse. WebRTC ne fonctionne pas, mais STUN oui
  • Notre logiciel de networking fait aussi du P2P, et c’est pour cela que nous avons tout implémenté en bande au lieu d’utiliser des approches génériques comme STUN ou TURN
    Ces approches se font parfois bloquer et sont souvent fragiles sur le plan de la sécurité
    STUN a désormais quelques mesures d’atténuation contre la militarisation, mais cela reste un protocole médiocre, et je ne comprends toujours pas pourquoi ni STUN ni TURN n’offrent le moindre moyen d’effectuer un rendez-vous sans voie de signalisation séparée. Cela aurait pourtant été facile à ajouter
  • Il suffit d’IPv6 et d’un code réseau implémenté au minimum en assembleur, sans fonctionnalités de niche ni complexité inutile

• Tout le monde le sait déjà, mais le meilleur dans les bibliothèques et applications open source ou à code source public, ce sont ces rapports de bugs et discussions de PR
  Voir des gens rassembler leurs symptômes, contournements et hypothèses sur la cause est vraiment réconfortant

  • Les discussions sur GitHub aussi avaient une bien meilleure qualité à l’époque où la plateforme était surtout fréquentée par des spécialistes
    Aujourd’hui, je vois souvent des discussions dériver en fils de type reddit/4chan, ce qui me donne une raison de plus de partir

• Le titre ne correspond pas au titre original de l’issue GitHub, « Major P2P issues in Israel and possibly other middle east countries »

• C’est une spéculation un peu brutale à la HN, mais si on lit jusqu’au bout l’issue GitHub, les utilisateurs signalent des échecs STUN
  Autrement dit, les liens P2P ne s’établissent pas et sont remplacés par des serveurs relais à forte latence
  Plusieurs utilisateurs ont contourné le problème en remplaçant manuellement par une ancienne dll WebRTC de Valve, et j’aimerais lire l’analyse post-mortem des développeurs de Valve

• Pourquoi la partie « in Israel and possibly other middle east countries » a-t-elle été retirée du titre ? Pour attirer les clics ?

  • Ou alors parce qu’il existe déjà suffisamment de fils de débat Israël/Palestine dans le monde, et qu’on voulait éviter que cela ne se transforme en un énième brasier
  • Si vous êtes ici depuis longtemps, vous savez qu’en ajoutant aussi cette formule on dépasserait la limite de caractères du titre

• C’est vraiment une soumission décevante, et j’ai du mal à croire qu’elle ait reçu autant de votes positifs
  Les gens ont probablement vu Valve dans le titre et pensé que c’était important, alors que le contenu réel de l’issue ne correspond même pas au titre

• Au départ, cela semblait être un gros problème P2P en Israël et dans certains pays du Moyen-Orient, mais après investigation supplémentaire, cela ressemble plutôt à un problème mondial

  • Jusqu’ici, le « mondial » semble désigner Israël, la Russie et la Chine
    Ce sont tous des pays peu favorables à la liberté d’internet et avec un long historique de surveillance et de censure ; cela pourrait donc être un effet secondaire de politiques réseau anti-P2P destinées à compliquer le contournement des FAI censeurs

• Cela ne semble pas être un problème de Valve
  Les problèmes signalés n’apparaissent apparemment que dans des pays qui scannent et filtrent les connexions de manière très agressive, et le P2P est sensible à ce type d’intervention
  SDR est un réseau relais chiffré, comparable à une forme de routage en oignon
  Il est bien connu qu’un acteur malveillant peut distribuer un jeu P2P puis l’utiliser pour faire transiter des communications via SDR
  Il est facile d’imaginer que certaines régions veuillent inspecter ce trafic

• Je suis en Chine, et il y a environ trois semaines j’ai joué à un jeu tiers via le jeu développeur Spacewar de Steam, probablement avec Steam P2P activé, et cela fonctionnait bien

• Rien qu’au titre, on dirait que c’est cassé partout