Masalah P2P besar yang terjadi di Israel dan beberapa negara Timur Tengah

• Status saat ini adalah Open, dan anggota ValveSoftware menyatakan kasus ini dapat digunakan bersama mitra yang memakai SDR untuk menyelidiki alasan "Share IP Address" tidak dipatuhi
• Dilaporkan bahwa sejak sekitar 13 Maret 2026, masalah terjadi pada game P2P yang menggunakan Steam Networking, dan pada Street Fighter 6, pertandingan PC-to-PC di Israel memiliki latensi sekitar 120ms, pertandingan melawan pemain Eropa 60~80ms, dan pertandingan PC-to-PS5 5~10ms
• Puluhan anggota komunitas di Israel mengalami masalah yang sama di berbagai ISP, dan meski sudah menghubungi ISP serta melakukan port forwarding, mereka tidak menemukan masalah jaringan; Tekken 8 yang tidak menggunakan Steam Networking dilaporkan tidak mengalami masalah
• Pemain di Tiongkok juga melaporkan bahwa di Warhammer: Vermintide 2, meski kedua pihak menyalakan "Share IP Address", koneksi P2P langsung tidak terbentuk, dan semua data pemain melewati relay SDR milik Steam sehingga latensi meningkat tajam
• Reproduksi tambahan menunjukkan bahwa jika trafik ke server SDR diblokir untuk memaksa koneksi P2P langsung, match online tidak akan dimulai
• Solusi sementara adalah menyalin steamwebrtc64.dll dari direktori instalasi Steam ke salah satu folder Binaries, Binaries/Win64, atau Binaries_dx12 di folder game; jika diterapkan oleh kedua pemain, akan muncul "NAT traversal successful, IP shared" dan koneksi P2P dipulihkan
• Solusi sementara tersebut dibagikan dengan konfirmasi berfungsi pada Deep Rock Galactic, Warhammer: Vermintide 2, dan Far Far West, serta kemudian ditambahkan kasus penerapan pada Street Fighter 6 dan Melty Blood
• Di Melty Blood, karena menggunakan steam_api.dll, yang dipakai adalah steamwebrtc.dll alih-alih steamwebrtc64.dll, dan jika tidak ada folder Binaries, file ditempatkan di folder yang sama dengan steam_api64.dll
• Seorang pengguna merangkum bahwa klien Steam lama menyiapkan P2P langsung dengan STUN, tetapi klien baru entah mengapa tidak mencoba melakukannya, meski perubahan pastinya belum diketahui

[GN⁺]

Komentar Hacker News

• Di sini tampaknya bukan Valve yang merusak segalanya, melainkan konflik di Timur Tengah meluas ke dunia siber dan dampaknya menjalar hingga pengguna sipil
  Waktu kejadiannya dan negara-negara yang terdampak mengarah ke sana, dan Tiongkok juga bukan tempat yang terkenal dengan internet bebas
  WebRTC bekerja sebagai jalur alternatif dan terenkripsi, serta sulit disalahgunakan untuk tujuan lain
  Sebaliknya, STUN tidak terenkripsi, dan protokol itu sendiri bisa dipakai untuk refleksi/amplifikasi DDoS, jadi tidak mengherankan jika ia telah dipersenjatai atau konektivitas rusak saat proses pemblokiran/analisis real-time

  • STUN/TURN di WebRTC pada dasarnya berperan hampir seperti icanhazip
    STUN memberi tahu IP:port publik, dan TURN mirip, tetapi mengembalikan IP:port yang dialokasikan secara dinamis pada saat kueri, bukan alamat sebenarnya
    Klien WebRTC mengirim respons STUN/TURN itu ke peer melalui jalur pensinyalan out-of-band seperti chat server lobi untuk membangun koneksi, dan memungkinkan dibuatnya entri pada tabel NAT kedua sisi seolah-olah itu koneksi keluar ke luar
    STUN/TURN saja tidak bisa membuat koneksi P2P; itu hanya alat yang dibutuhkan WebRTC
  • Saya pernah membuat VPN P2P mirip WireGuard di atas WebRTC, dan performanya bagus, di atas 300Mbps
    Karena pengguna akhir tidak perlu memikirkan masalah firewall atau perbedaan IPv4/IPv6, saya rasa WebRTC bisa disesuaikan untuk game P2P real-time atau jaringan perusahaan alih-alih solusi berbasis IP
  • Sepertinya Anda memahaminya terbalik. WebRTC yang tidak jalan, STUN justru jalan
  • Perangkat lunak jaringan kami juga memakai P2P, jadi karena itu kami mengimplementasikan semuanya sebagai penanganan in-band, bukan dengan cara umum seperti STUN atau TURN
    Cara-cara seperti itu kadang diblokir dan sering juga lemah dari sisi keamanan
    Memang sekarang ada mitigasi terhadap persenjataan STUN, tetapi itu tetap protokol yang buruk, dan saya tidak paham kenapa baik STUN maupun TURN sama sekali tidak punya cara untuk melakukan rendezvous tanpa jalur pensinyalan terpisah. Padahal mestinya mudah ditambahkan
  • Cukup dengan IPv6 dan kode jaringan implementasi minimal dalam assembly tanpa fitur-fitur niche yang rumit

• Mungkin semua orang sudah tahu, tetapi hal terbaik dari library dan aplikasi open source atau yang source-nya terbuka adalah laporan bug dan diskusi PR seperti ini
  Sangat menyenangkan melihat banyak orang mengumpulkan gejala, cara обход, dan hipotesis penyebab dari sudut masing-masing

  • Diskusi GitHub juga dulu jauh lebih berkualitas ketika platform itu masih berpusat pada para ahli
    Sekarang saya sering melihat banyak diskusi praktis mengalir seperti thread reddit/4chan, jadi itu menambah satu alasan lagi untuk pergi

• Judulnya tidak cocok dengan judul asli issue GitHub, yaitu "Major P2P issues in Israel and possibly other middle east countries"

• Ini memang spekulasi kasar ala HN, tetapi kalau membaca issue GitHub sampai akhir, para pengguna melaporkan kegagalan STUN
  Artinya link P2P tidak terbentuk dan digantikan oleh server relay berlatensi tinggi
  Sejumlah pengguna mengakali masalah itu dengan mengganti secara manual ke dll WebRTC Valve yang lama, dan saya ingin membaca analisis paska-insiden dari para developer Valve

• Kenapa bagian "in Israel and possibly other middle east countries" dihapus dari judul? Umpan klik?

  • Atau mungkin karena sudah ada cukup banyak thread perdebatan Israel/Palestina di dunia, dan ingin menghindari topik ini berkembang menjadi ajang ribut lagi
  • Kalau sudah lama di sini, orang seharusnya tahu bahwa kalau frasa itu ikut dimasukkan akan melewati batas jumlah karakter judul

• Ini kiriman yang benar-benar mengecewakan, dan sulit dipercaya bisa mendapat begitu banyak upvote
  Sepertinya orang menganggapnya penting hanya karena melihat Valve di judul, padahal isi issue yang sebenarnya bahkan tidak sesuai dengan judulnya

• Awalnya ini dimulai sebagai masalah P2P besar di Israel dan beberapa negara Timur Tengah, tetapi investigasi tambahan membuatnya terlihat seperti masalah global

  • Sejauh ini, "global" berarti Israel, Rusia, dan Tiongkok
    Semuanya adalah negara yang tidak terlalu menyukai kebebasan internet dan punya sejarah panjang pengawasan serta sensor, jadi ini bisa jadi efek samping dari kebijakan jaringan P2P untuk mempersulit penghindaran sensor ISP

• Ini tampaknya bukan masalah Valve
  Masalah yang dilaporkan tampaknya hanya muncul di negara-negara yang memindai dan memfilter koneksi dengan sangat agresif, dan P2P sensitif terhadap intervensi seperti ini
  SDR adalah jaringan relay terenkripsi, mirip sesuatu seperti onion routing
  Sudah diketahui luas bahwa pelaku jahat bisa mendistribusikan game P2P lalu menjalankan komunikasi di atas SDR melalui game itu
  Mudah dibayangkan bahwa di wilayah seperti ini ada keinginan untuk memeriksa lalu lintas tersebut

• Saya berada di Tiongkok, dan sekitar 3 minggu lalu memainkan game pihak ketiga melalui game pengembang Spacewar milik Steam, kemungkinan dengan Steam P2P aktif, dan semuanya berjalan baik

• Kalau hanya melihat judulnya, ini tampak seperti rusak di mana-mana