Principais problemas de P2P ocorridos em Israel e em alguns países do Oriente Médio

• O status atual é Open, e a posição de um membro da ValveSoftware é que esse caso pode ser usado na investigação do motivo pelo qual "Share IP Address" não está sendo respeitado, em conjunto com parceiros que usam SDR
• Por volta de 13 de março de 2026, começaram a ocorrer problemas em jogos P2P que usam Steam Networking, e houve relatos de que partidas PC contra PC de Street Fighter 6 em Israel apresentavam cerca de 120 ms, partidas contra jogadores europeus ficavam em 60~80 ms, e partidas PC contra PS5 ficavam em 5~10 ms
• Dezenas de pessoas da comunidade de Israel relataram o mesmo problema em vários ISPs, e, mesmo após contato com os provedores e configuração de port forwarding, não encontraram problemas de rede; também houve relatos de que Tekken 8, que não usa Steam Networking, não apresentava esse problema
• Jogadores da China também relataram que, em Warhammer: Vermintide 2, mesmo com "Share IP Address" ativado nos dois lados, uma conexão P2P direta não era estabelecida, e todos os dados dos jogadores passavam pelo relay SDR da Steam, aumentando drasticamente a latência
• Houve reprodução adicional mostrando que, ao bloquear o tráfego para servidores SDR para forçar uma conexão P2P direta, a partida online não inicia
• Como solução temporária, ao copiar steamwebrtc64.dll do diretório de instalação da Steam para uma das pastas Binaries, Binaries/Win64 ou Binaries_dx12 do jogo, e aplicando isso em ambos os jogadores, aparece "NAT traversal successful, IP shared" e a conexão P2P é restaurada
• Essa solução temporária foi compartilhada com confirmação de funcionamento em Deep Rock Galactic, Warhammer: Vermintide 2 e Far Far West, e depois foram adicionados casos de aplicação também em Street Fighter 6 e Melty Blood
• Em Melty Blood, como é usado steam_api.dll, foi necessário usar steamwebrtc.dll em vez de steamwebrtc64.dll; quando não havia pasta Binaries, o arquivo foi colocado na mesma pasta de steam_api64.dll
• Um usuário resumiu que o cliente antigo da Steam configurava P2P direto via STUN, mas o cliente novo, por algum motivo, não tenta mais fazer isso; o estado atual é que a mudança exata ainda não é conhecida

[GN⁺]

Comentários do Hacker News

• Aqui, ao que parece, não foi tanto a Valve que quebrou algo, mas sim a expansão do conflito no Oriente Médio para o ciberespaço, afetando também usuários civis
  O momento e os países afetados apontam nessa direção, e a China também não é exatamente conhecida por uma internet livre
  O WebRTC funciona como rota alternativa, é criptografado e também é difícil de abusar para outros fins
  Já o STUN não é criptografado, e o próprio protocolo pode ser usado para reflexão/amplificação em DDoS, então não seria surpreendente se tivesse sido militarizado ou se a conectividade tivesse se quebrado durante bloqueios/análises em tempo real

  • STUN/TURN no WebRTC faz quase o papel de um icanhazip
    O STUN informa o IP:porta público, e o TURN é parecido, mas em vez do endereço real devolve um IP:porta alocado dinamicamente no momento da consulta
    O cliente WebRTC envia essa resposta de STUN/TURN ao par por um caminho de sinalização fora de banda, como o chat do servidor de lobby, para estabelecer a conexão e permitir criar entradas nas tabelas NAT dos dois lados como se fossem conexões de saída
    Só com STUN/TURN não dá para criar uma conexão P2P; são apenas ferramentas necessárias para o WebRTC
  • Já fiz uma VPN P2P parecida com WireGuard sobre WebRTC, e o desempenho foi bom, acima de 300 Mbps
    Como o usuário final não precisa se preocupar com firewall nem com diferenças entre IPv4/IPv6, acho que dá para adaptar o WebRTC para jogos P2P em tempo real ou redes corporativas, em vez de soluções baseadas em IP
  • Acho que você entendeu ao contrário. WebRTC não funciona, mas STUN funciona
  • Nosso software de rede também usa P2P, então por isso implementamos tudo em banda, em vez de usar métodos comuns como STUN e TURN
    Esses métodos às vezes são bloqueados e muitas vezes também têm segurança fraca
    O STUN hoje já tem mitigação contra militarização, mas ainda assim continua sendo um protocolo horrível, e não entendo como STUN ou TURN não têm absolutamente nenhum jeito de fazer rendezvous sem um caminho de sinalização separado. Teria sido fácil incluir isso
  • IPv6 e um código de rede mínimo implementado em assembly, sem recursos de nicho e complexos, já bastam

• Isso todo mundo já sabe, mas uma das melhores coisas em bibliotecas e aplicações open source ou com código aberto são esses relatos de bug e discussões de PR
  É muito bom ver várias pessoas juntando seus sintomas, soluções de contorno e hipóteses de causa

  • As discussões no GitHub também tinham qualidade muito maior quando a plataforma era mais voltada a especialistas
    Hoje em dia, vejo com frequência muitas discussões virando praticamente threads de reddit/4chan, então esse é mais um motivo para ir embora

• O título não bate com o original da issue no GitHub: "Major P2P issues in Israel and possibly other middle east countries"

• É especulação bruta no estilo HN, mas se você ler até o fim da issue no GitHub, os usuários estão reportando falhas de STUN
  Ou seja, o link P2P não é estabelecido e acaba sendo substituído por um servidor de relay com alta latência
  Vários usuários contornaram o problema trocando manualmente por uma dll antiga do Valve WebRTC, e eu gostaria de ler a análise pós-incidente dos desenvolvedores da Valve

• Por que tiraram do título a parte "in Israel and possibly other middle east countries"? Foi para atrair cliques?

  • Ou talvez porque já existam threads demais de debate Israel/Palestina no mundo, e quisessem evitar que isso virasse mais uma fogueira
  • Quem está aqui há bastante tempo saberia que, incluindo essa parte, o limite de caracteres do título seria ultrapassado

• É um envio realmente sem graça, e não dá para acreditar que recebeu tantos votos
  As pessoas parecem ter achado importante só por causa de Valve no título, mas o conteúdo real da issue nem corresponde ao título

• No começo parecia um grande problema de P2P em Israel e em alguns países do Oriente Médio, mas depois de mais investigação passou a parecer um problema global

  • Até agora, esse "global" quer dizer algo como Israel, Rússia e China
    Todos são países sem grande apreço por liberdade na internet e com longo histórico de vigilância e censura, então isso pode ser um efeito colateral de políticas de rede contra P2P voltadas a dificultar a evasão de ISP censores

• Isso não parece ser um problema da Valve
  Os problemas relatados parecem ocorrer apenas em países que fazem varredura e filtragem muito agressivas das conexões, e P2P é sensível a esse tipo de interferência
  O SDR é uma rede de relay criptografada, parecida com onion routing
  É bem conhecido que um agente malicioso poderia distribuir um jogo P2P e depois usar esse jogo para trafegar comunicação sobre o SDR
  É fácil imaginar que, nessas regiões, haja interesse em inspecionar esse tráfego

• Estou na China e, umas 3 semanas atrás, joguei um jogo de terceiros por meio do jogo de desenvolvedor Spacewar da Steam e provavelmente com Steam P2P ligado, e funcionou bem

• Pelo título, parece que quebrou em todo lugar