이스라엘 및 중동 일부 국가에서 발생한 주요 P2P 문제

• 현재 상태는 Open이며, ValveSoftware 멤버는 SDR을 사용하는 파트너와 함께 "Share IP Address"가 지켜지지 않는 이유를 조사하는 데 해당 사례를 활용할 수 있다는 입장
• 2026년 3월 13일경부터 Steam Networking을 쓰는 P2P 게임에서 문제가 발생했고, Street Fighter 6의 이스라엘 PC-to-PC 대전은 약 120ms, 유럽 플레이어와의 대전은 60~80ms, PC-to-PS5 대전은 5~10ms였다는 보고
• 이스라엘 커뮤니티의 수십 명이 여러 ISP에서 같은 문제를 겪었고, ISP 문의와 포트 포워딩 후에도 네트워크 문제를 찾지 못했으며, Steam Networking을 쓰지 않는 Tekken 8에서는 문제가 없었다는 보고
• 중국 플레이어도 Warhammer: Vermintide 2에서 양쪽 모두 "Share IP Address"를 켜도 직접 P2P 연결이 성립하지 않고, 모든 플레이어 데이터가 Steam의 SDR 릴레이를 거쳐 지연 시간이 급증했다는 보고
• SDR 서버 트래픽을 차단해 직접 P2P 연결을 강제하려 하면 온라인 매치가 시작되지 않는다는 추가 재현
• steamwebrtc64.dll을 Steam 설치 디렉터리에서 게임 폴더의 Binaries, Binaries/Win64, Binaries_dx12 중 하나로 복사하고 양쪽 플레이어가 모두 적용하면 "NAT traversal successful, IP shared"가 표시되며 P2P 연결이 복구된다는 임시 우회책
• 해당 우회책은 Deep Rock Galactic, Warhammer: Vermintide 2, Far Far West에서 동작 확인으로 공유되었고, Street Fighter 6와 Melty Blood에서도 적용 사례가 추가됨
• Melty Blood에서는 steam_api.dll을 사용하므로 steamwebrtc64.dll이 아니라 steamwebrtc.dll을 사용해야 했고, Binaries 폴더가 없는 경우 steam_api64.dll과 같은 폴더에 배치했다는 적용 기록
• 한 사용자는 구 Steam 클라이언트가 STUN으로 직접 P2P를 설정하지만, 새 클라이언트는 어떤 이유로 이를 시도하지 않는다고 정리했으며 정확한 변경점은 알 수 없다는 상태

[GN⁺]

Hacker News 의견들

• 여기서는 Valve가 망가뜨렸다기보다 중동 분쟁이 사이버공간으로 확장되면서 민간 사용자에게까지 영향이 번진 것으로 보임
  시점과 영향을 받은 국가들을 보면 그렇고, 중국도 자유로운 인터넷으로 유명한 곳은 아님
  WebRTC는 대체 경로로 동작하며 암호화되어 있고 다른 용도로 악용하기도 어려움
  반면 STUN은 암호화되지 않았고 프로토콜 자체가 DDoS 반사/증폭에 쓰일 수 있어서, 무기화되었거나 실시간 차단·분석 과정에서 연결성이 깨졌을 가능성도 놀랍지 않음

  • STUN/TURN은 WebRTC에서 거의 icanhazip 같은 역할임
    STUN은 공개 IP:포트를 알려주고, TURN도 비슷하지만 실제 주소가 아니라 질의 시점에 동적으로 할당된 IP:포트를 돌려줌
    WebRTC 클라이언트는 그 STUN/TURN 응답을 로비 서버 채팅 같은 대역 외 신호 경로로 피어에게 보내 연결을 설정하고, 양쪽 NAT 테이블에 마치 외부로 나가는 연결인 것처럼 항목을 만들 수 있게 함
    STUN/TURN만으로는 P2P 연결을 만들 수 없고, WebRTC에 필요한 도구일 뿐임
  • WebRTC 위에서 WireGuard 비슷한 P2P VPN을 만들어봤는데 성능이 300Mbps 이상으로 좋았음
    최종 사용자가 방화벽 문제나 IPv4/IPv6 차이를 신경 쓰지 않아도 되니, IP 기반 해법 대신 실시간 P2P 게임이나 기업 네트워킹 등에 WebRTC를 맞춰 쓸 수 있다고 봄
  • 반대로 이해한 것 같음. WebRTC가 안 되고 STUN은 됨
  • 우리 네트워킹 소프트웨어도 P2P를 하는데, 그래서 STUN, TURN 같은 일반적인 방식 대신 전부 대역 내 처리로 구현함
    그런 방식들은 차단되기도 하고 보안도 취약한 경우가 많음
    STUN에는 이제 무기화 완화책이 있긴 하지만 여전히 형편없는 프로토콜이고, STUN이나 TURN 어느 쪽에도 별도의 신호 경로 없이 랑데부를 수행할 방법이 전혀 없다는 게 이해되지 않음. 쉽게 넣을 수 있었을 텐데
  • IPv6와, 틈새적이고 복잡한 기능 없이 어셈블리로 최소 구현한 네트워크 코드면 됨

• 이미 다들 아는 얘기겠지만, 오픈소스나 소스가 공개된 라이브러리·애플리케이션에서 가장 좋은 점은 이런 버그 리포트와 PR 논의임
  여러 사람이 각자의 증상, 우회 방법, 원인 가설을 모아가는 모습이 정말 훈훈함

  • GitHub 논의도 플랫폼이 전문가 중심이던 시절에는 훨씬 품질이 높았음
    요즘은 많은 논의가 사실상 reddit/4chan 스레드처럼 흘러가는 걸 자주 봐서, 떠나야 할 이유가 하나 더 늘었음

• 제목이 GitHub 이슈의 원제인 "Major P2P issues in Israel and possibly other middle east countries"와 맞지 않음

• HN식 거친 추측이긴 하지만, GitHub 이슈 끝까지 읽어보면 사용자들이 STUN 실패를 보고하고 있음
  즉 P2P 링크가 수립되지 않고 지연 시간이 큰 릴레이 서버로 대체되는 상황임
  여러 사용자는 오래된 Valve WebRTC dll로 수동 교체해 문제를 우회했고, Valve 개발자들의 사후 분석을 읽어보고 싶음

• "in Israel and possibly other middle east countries" 부분은 왜 제목에서 뺐나? 클릭 유도인가?

  • 아니면 세상에 이미 충분히 많은 이스라엘/팔레스타인 논쟁 스레드가 있고, 또 하나의 불판으로 번지는 걸 피하려던 것일 수도 있음
  • 여기 오래 있었으면 그 문구까지 넣으면 제목 글자 수 제한을 넘긴다는 걸 알 만함

• 정말 맥 빠지는 제출물인데 이렇게 추천을 많이 받은 게 믿기지 않음
  사람들이 제목의 Valve만 보고 중요하다고 여긴 것 같지만, 실제 이슈 내용은 제목과도 맞지 않음

• 처음에는 이스라엘과 일부 중동 국가의 큰 P2P 문제로 시작했지만, 추가 조사 결과 전 세계적 문제처럼 보이게 됨

  • 지금까지의 "전 세계"는 이스라엘, 러시아, 중국 정도를 뜻함
    모두 인터넷 자유를 딱히 좋아하지 않고 감시와 검열의 역사가 긴 국가들이라, 검열 ISP 우회를 어렵게 하려는 P2P 네트워크 정책의 부작용일 수 있음

• 이건 Valve 문제가 아닌 것처럼 보임
  보고된 문제들은 연결을 매우 공격적으로 스캔하고 필터링하는 국가들에서만 나타나는 듯하고, P2P는 이런 개입에 민감함
  SDR은 암호화된 릴레이 네트워크라 양파 라우팅 같은 것과 비슷함
  악의적 행위자가 P2P 게임을 배포한 뒤 그 게임을 통해 SDR 위에서 통신을 돌릴 수 있다는 건 잘 알려져 있음
  이런 지역에서 그 트래픽을 검사하고 싶어 할 수 있다는 건 쉽게 상상됨

• 중국에 있는데 3주 전쯤 Steam의 Spacewar 개발자용 게임을 통해 서드파티 게임을 했고, 아마 Steam P2P가 켜진 상태였는데 잘 동작했음

• 제목만 보면 어디서나 고장 난 것처럼 보임