Problema importante de P2P ocurrido en Israel y algunos países de Medio Oriente

• El estado actual es Open, y la postura de los miembros de ValveSoftware es que este caso puede servir para investigar por qué no se está respetando "Share IP Address" junto con socios que usan SDR
• Se reportó que desde alrededor del 13 de marzo de 2026 comenzaron a ocurrir problemas en juegos P2P que usan Steam Networking; en Street Fighter 6, los enfrentamientos PC a PC en Israel tenían unos 120 ms, contra jugadores europeos 60 a 80 ms, y los enfrentamientos de PC a PS5 5 a 10 ms
• Decenas de personas de la comunidad de Israel reportaron el mismo problema en varios ISP, y que incluso después de consultar con el ISP y configurar port forwarding no pudieron encontrar problemas de red; también reportaron que en Tekken 8, que no usa Steam Networking, no había inconvenientes
• Jugadores de China también reportaron que en Warhammer: Vermintide 2 no se establecía una conexión P2P directa aunque ambos lados activaran "Share IP Address", y que todos los datos de los jugadores pasaban por el relay SDR de Steam, disparando la latencia
• También se reprodujo adicionalmente que, al bloquear el tráfico hacia los servidores SDR para forzar una conexión P2P directa, la partida online no llegaba a iniciarse
• Como solución temporal, se indicó que al copiar steamwebrtc64.dll desde el directorio de instalación de Steam a una de las carpetas Binaries, Binaries/Win64 o Binaries_dx12 del juego, y aplicarlo en ambos jugadores, aparecía "NAT traversal successful, IP shared" y se restauraba la conexión P2P
• Se compartió que esta solución temporal fue confirmada como funcional en Deep Rock Galactic, Warhammer: Vermintide 2 y Far Far West, y luego se sumaron casos de aplicación en Street Fighter 6 y Melty Blood
• En Melty Blood, como se usa steam_api.dll, hubo que usar steamwebrtc.dll en lugar de steamwebrtc64.dll; además, si no existía la carpeta Binaries, se colocó en la misma carpeta que steam_api64.dll
• Un usuario resumió que el cliente antiguo de Steam sí configuraba P2P directo mediante STUN, pero que el cliente nuevo por alguna razón no intenta hacerlo, y que el cambio exacto aún no está claro

[GN⁺]

Comentarios en Hacker News

• Aquí parece menos que Valve lo haya roto y más que el conflicto en Medio Oriente se extendió al ciberespacio, afectando también a usuarios civiles
  Por el momento en que ocurrió y los países afectados, tiene sentido; China tampoco es precisamente famosa por tener un internet libre
  WebRTC funciona como ruta alternativa, está cifrado y además es difícil de reutilizar para otros fines
  En cambio, STUN no está cifrado, y como el protocolo en sí puede usarse para reflexión/amplificación de DDoS, no sorprendería que haya sido militarizado o que la conectividad se haya roto durante procesos de bloqueo o análisis en tiempo real

  • STUN/TURN en WebRTC cumple casi el papel de icanhazip
    STUN te dice tu IP:puerto pública, y TURN es parecido, pero devuelve una IP:puerto asignada dinámicamente al momento de la consulta en vez de la dirección real
    Los clientes WebRTC envían esa respuesta de STUN/TURN al par mediante una ruta de señalización fuera de banda, como el chat de un servidor de lobby, para establecer la conexión y permitir crear entradas en ambas tablas NAT como si fueran conexiones salientes
    Solo con STUN/TURN no se puede crear una conexión P2P; son solo herramientas necesarias para WebRTC
  • Probé construir una VPN P2P tipo WireGuard sobre WebRTC y el rendimiento fue bueno, más de 300 Mbps
    Como el usuario final no tiene que preocuparse por problemas de firewall ni por diferencias entre IPv4/IPv6, creo que WebRTC se puede adaptar para juegos P2P en tiempo real o redes corporativas, en lugar de usar soluciones basadas en IP
  • Creo que lo entendiste al revés. WebRTC no funciona y STUN sí
  • Nuestro software de redes también hace P2P, y por eso en vez de usar métodos comunes como STUN o TURN, lo implementamos todo en banda
    Ese tipo de métodos suelen bloquearse y además muchas veces son débiles en seguridad
    STUN ya tiene mitigaciones contra su uso como arma, pero sigue siendo un protocolo pésimo, y no entiendo por qué ni STUN ni TURN tienen ninguna forma de hacer rendezvous sin una ruta de señalización separada. Habría sido fácil incluirlo
  • Basta con IPv6 y código de red mínimo implementado en ensamblador, sin funciones de nicho ni complejas

• Esto ya lo sabe todo el mundo, pero una de las mejores cosas del open source o de las librerías y aplicaciones con código público son estos reportes de bugs y discusiones de PR
  Da gusto ver a varias personas juntando sus síntomas, soluciones temporales e hipótesis sobre la causa

  • Las discusiones en GitHub también eran de mucha más calidad cuando la plataforma estaba más orientada a especialistas
    Últimamente muchas discusiones terminan pareciéndose en la práctica a hilos de reddit/4chan, así que ya tengo un motivo más para irme

• El título no coincide con el título original del issue en GitHub: "Major P2P issues in Israel and possibly other middle east countries"

• Es especulación al estilo HN, pero si lees hasta el final del issue en GitHub, los usuarios están reportando fallas de STUN
  Es decir, el enlace P2P no se establece y se reemplaza por servidores de relay con alta latencia
  Varios usuarios evitaron el problema reemplazando manualmente por una dll vieja de Valve WebRTC, y me gustaría leer el análisis posterior de los desarrolladores de Valve

• ¿Por qué quitaron del título la parte de "in Israel and possibly other middle east countries"? ¿Clickbait?

  • O tal vez pensaron que ya hay suficientes hilos de debate Israel/Palestina en el mundo y quisieron evitar que esto se convirtiera en otra fogata
  • Si llevas tiempo aquí, sabrás que incluir también esa frase haría que se exceda el límite de caracteres del título

• Es una publicación realmente decepcionante, y no puedo creer que haya recibido tantos votos
  Parece que la gente vio Valve en el título y asumió que era importante, pero el contenido real del issue ni siquiera coincide con el título

• Al principio parecía un gran problema de P2P en Israel y algunos países de Medio Oriente, pero tras investigar más parece ser un problema global

  • Hasta ahora, ese "global" parece referirse a Israel, Rusia y China
    Todos son países poco entusiastas del internet libre y con una larga historia de vigilancia y censura, así que podría ser un efecto secundario de políticas de red contra P2P orientadas a dificultar la evasión de ISP censores

• Esto no parece ser un problema de Valve
  Los problemas reportados parecen aparecer solo en países que escanean y filtran conexiones de forma muy agresiva, y P2P es sensible a ese tipo de intervención
  SDR es una red de relay cifrada, parecida al onion routing
  Es bien sabido que un actor malicioso podría distribuir un juego P2P y luego usar ese juego para comunicarse sobre SDR
  Es fácil imaginar que quieran inspeccionar ese tráfico en estas regiones

• Estoy en China; hace unas 3 semanas jugué un juego de terceros usando el juego de desarrolladores Spacewar de Steam, probablemente con Steam P2P activado, y funcionó bien

• Por el puro título, parece que estuviera roto en todas partes