Größeres P2P-Problem in Israel und einigen Ländern des Nahen Ostens aufgetreten

• Der aktuelle Status ist Open. ValveSoftware-Mitglieder erklärten, dass dieser Fall genutzt werden könne, um gemeinsam mit Partnern, die SDR verwenden, zu untersuchen, warum "Share IP Address" nicht eingehalten wird.
• Berichten zufolge treten seit etwa dem 13. März 2026 Probleme in P2P-Spielen auf, die Steam Networking verwenden. Bei Street Fighter 6 lagen PC-zu-PC-Matches in Israel bei etwa 120 ms, Matches gegen europäische Spieler bei 60–80 ms und PC-zu-PS5-Matches bei 5–10 ms.
• Dutzende Mitglieder der israelischen Community berichteten über dasselbe Problem bei verschiedenen ISPs. Auch nach Kontakt mit den ISPs und Port-Forwarding konnten keine Netzwerkprobleme gefunden werden; bei Tekken 8, das Steam Networking nicht verwendet, trat das Problem nicht auf.
• Auch ein chinesischer Spieler berichtete, dass in Warhammer: Vermintide 2 keine direkte P2P-Verbindung zustande kommt, selbst wenn beide Seiten "Share IP Address" aktivieren, und dass sämtliche Spielerdaten über Steams SDR-Relay geleitet werden, wodurch die Latenz stark ansteigt.
• Zusätzlich wurde reproduziert, dass ein Online-Match nicht startet, wenn man den Verkehr zu den SDR-Servern blockiert, um eine direkte P2P-Verbindung zu erzwingen.
• Als temporärer Workaround wurde genannt, steamwebrtc64.dll aus dem Steam-Installationsverzeichnis in einem der Spielordner Binaries, Binaries/Win64 oder Binaries_dx12 zu kopieren. Wenn beide Spieler dies anwenden, erscheint "NAT traversal successful, IP shared" und die P2P-Verbindung wird wiederhergestellt.
• Dieser Workaround wurde als funktionierend für Deep Rock Galactic, Warhammer: Vermintide 2 und Far Far West geteilt; später kamen auch Anwendungsfälle für Street Fighter 6 und Melty Blood hinzu.
• Bei Melty Blood wird steam_api.dll verwendet, daher musste statt steamwebrtc64.dll die Datei steamwebrtc.dll genutzt werden. Falls kein Binaries-Ordner vorhanden war, wurde sie im selben Ordner wie steam_api64.dll abgelegt.
• Ein Nutzer fasste zusammen, dass der alte Steam-Client direkte P2P-Verbindungen per STUN einrichtet, während der neue Client dies aus irgendeinem Grund nicht versucht; welche Änderung genau dafür verantwortlich ist, ist weiterhin unklar.

[GN⁺]

Hacker-News-Kommentare

• Hier sieht es weniger so aus, als hätte Valve etwas kaputtgemacht, sondern eher so, als ob sich der Konflikt im Nahen Osten in den Cyberspace ausgeweitet hätte und nun auch zivile Nutzer betroffen sind
  Zeitpunkt und betroffene Länder deuten darauf hin, und China ist ebenfalls nicht gerade für ein freies Internet bekannt
  WebRTC arbeitet über alternative Pfade, ist verschlüsselt und lässt sich auch nur schwer für andere Zwecke missbrauchen
  STUN hingegen ist nicht verschlüsselt, und das Protokoll selbst kann für DDoS-Reflexion/-Verstärkung genutzt werden, daher wäre es nicht überraschend, wenn es entweder bewaffnet wurde oder die Konnektivität bei Echtzeit-Blockierung bzw. -Analyse kaputtgeht

  • STUN/TURN erfüllt bei WebRTC fast eine Rolle wie icanhazip
    STUN teilt die öffentliche IP:Port-Kombination mit, TURN ist ähnlich, gibt aber nicht die echte Adresse zurück, sondern eine zum Zeitpunkt der Anfrage dynamisch zugewiesene IP:Port-Kombination
    WebRTC-Clients senden diese STUN/TURN-Antwort dann über einen Out-of-Band-Signalisierungspfad wie etwa einen Lobbyserver-Chat an den Peer, um die Verbindung aufzubauen, und können so auf beiden Seiten NAT-Tabelleneinträge erzeugen, die wie ausgehende Verbindungen nach außen wirken
    Mit STUN/TURN allein lässt sich keine P2P-Verbindung herstellen; es ist nur ein für WebRTC benötigtes Werkzeug
  • Ich habe einmal ein P2P-VPN gebaut, ähnlich wie WireGuard, auf Basis von WebRTC, und die Leistung war mit über 300 Mbps gut
    Da Endnutzer sich dann nicht um Firewall-Probleme oder IPv4/IPv6-Unterschiede kümmern müssen, könnte man WebRTC statt IP-basierter Lösungen gut auf Echtzeit-P2P-Spiele oder Unternehmensnetzwerke zuschneiden
  • Ich glaube, du hast es umgekehrt verstanden. WebRTC funktioniert nicht, STUN aber schon
  • Unsere Netzwerksoftware macht ebenfalls P2P, deshalb setzen wir statt auf übliche Verfahren wie STUN oder TURN vollständig auf In-Band-Verarbeitung
    Solche Verfahren werden oft blockiert und sind sicherheitstechnisch häufig schwach
    Für STUN gibt es inzwischen zwar Gegenmaßnahmen gegen eine Bewaffnung, aber es bleibt trotzdem ein miserables Protokoll, und ich verstehe nicht, warum weder STUN noch TURN irgendeine Möglichkeit bieten, Rendezvous ohne separaten Signalisierungspfad durchzuführen. Das hätte sich leicht einbauen lassen
  • IPv6 und in Assembler minimal implementierter Netzwerkcode ohne nischige, komplexe Funktionen reichen aus

• Das wissen zwar schon alle, aber das Beste an Open-Source- oder quelloffenen Bibliotheken und Anwendungen sind genau solche Bug-Reports und PR-Diskussionen
  Es ist wirklich schön zu sehen, wie viele Leute ihre jeweiligen Symptome, Workarounds und Ursache-Hypothesen zusammentragen

  • Auch GitHub-Diskussionen waren deutlich hochwertiger, als die Plattform noch stärker von Fachleuten geprägt war
    Heute laufen viele Diskussionen faktisch wie reddit-/4chan-Threads ab, und das ist noch ein weiterer Grund zu gehen

• Der Titel passt nicht zum Originaltitel des GitHub-Issues: "Major P2P issues in Israel and possibly other middle east countries"

• Das ist zwar raues HN-typisches Rätselraten, aber wenn man das GitHub-Issue bis zum Ende liest, melden Nutzer STUN-Fehlschläge
  Das heißt, die P2P-Verbindung kommt nicht zustande und stattdessen wird auf Relay-Server mit hoher Latenz ausgewichen
  Mehrere Nutzer haben das Problem umgangen, indem sie manuell eine ältere Valve-WebRTC-dll eingesetzt haben, und ich würde gern die nachträgliche Analyse der Valve-Entwickler dazu lesen

• Warum wurde der Teil "in Israel and possibly other middle east countries" aus dem Titel entfernt? Clickbait?

  • Oder man wollte vermeiden, dass daraus noch ein weiterer Thread mit Israel/Palästina-Debatten wird, davon gibt es ohnehin schon mehr als genug
  • Wenn man lange genug hier ist, weiß man, dass man mit diesem Zusatz die Zeichenbegrenzung für Titel überschritten hätte

• Das ist wirklich eine enttäuschende Einreichung, und ich kann kaum glauben, wie viele Empfehlungen sie bekommen hat
  Die Leute haben wahrscheinlich nur Valve im Titel gesehen und es deshalb für wichtig gehalten, aber der eigentliche Inhalt des Issues passt nicht einmal zum Titel

• Zuerst wirkte es wie ein großes P2P-Problem in Israel und einigen Ländern des Nahen Ostens, aber nach weiteren Untersuchungen scheint es eher ein weltweites Problem zu sein

  • „Weltweit“ bedeutet bisher Israel, Russland und China
    Alles Länder, die Internetfreiheit nicht gerade schätzen und eine lange Geschichte von Überwachung und Zensur haben, daher könnte es ein Nebeneffekt von P2P-Netzwerkrichtlinien sein, die Umgehungen zensierender ISPs erschweren sollen

• Es sieht nicht nach einem Problem bei Valve aus
  Die gemeldeten Probleme scheinen nur in Ländern aufzutreten, die Verbindungen sehr aggressiv scannen und filtern, und P2P ist empfindlich gegenüber solchen Eingriffen
  SDR ist ein verschlüsseltes Relay-Netzwerk und ähnelt Dingen wie Onion Routing
  Es ist gut bekannt, dass böswillige Akteure ein P2P-Spiel verbreiten und darüber Kommunikation über SDR laufen lassen könnten
  Dass man diesen Datenverkehr in solchen Regionen inspizieren möchte, ist leicht vorstellbar

• Ich bin in China und habe vor etwa drei Wochen über Steams Entwickler-Spiel Spacewar ein Drittanbieter-Spiel gespielt, vermutlich mit aktiviertem Steam P2P, und es hat gut funktioniert

• Vom Titel her wirkt es so, als wäre es überall kaputt