Sự cố P2P nghiêm trọng xảy ra tại Israel và một số quốc gia Trung Đông

 (github.com/ValveSoftware)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trạng thái hiện tại là Open, và phía thành viên ValveSoftware cho biết có thể sử dụng trường hợp này để điều tra vì sao "Share IP Address" không được tuân thủ, cùng với các đối tác đang sử dụng SDR
  • Từ khoảng ngày 13 tháng 3 năm 2026, sự cố bắt đầu xảy ra trong các game P2P dùng Steam Networking; có báo cáo rằng trận đối kháng PC-to-PC của Street Fighter 6 tại Israel có độ trễ khoảng 120ms, trận với người chơi châu Âu là 60~80ms, còn trận PC-to-PS5 là 5~10ms
  • Hàng chục người trong cộng đồng Israel gặp cùng một vấn đề trên nhiều ISP khác nhau; ngay cả sau khi liên hệ ISP và cấu hình port forwarding, họ vẫn không tìm ra vấn đề mạng nào, và Tekken 8, vốn không dùng Steam Networking, thì không gặp lỗi này
  • Người chơi Trung Quốc cũng báo cáo rằng trong Warhammer: Vermintide 2, ngay cả khi cả hai bên đều bật "Share IP Address", kết nối P2P trực tiếp vẫn không được thiết lập, và toàn bộ dữ liệu người chơi đều phải đi qua relay SDR của Steam, khiến độ trễ tăng vọt
  • Có thêm tái hiện cho thấy nếu chặn lưu lượng tới máy chủ SDR để ép dùng kết nối P2P trực tiếp thì trận đấu online sẽ không khởi động
  • Một cách lách tạm thời là sao chép steamwebrtc64.dll từ thư mục cài đặt Steam vào một trong các thư mục Binaries, Binaries/Win64, Binaries_dx12 của game; nếu cả hai người chơi cùng áp dụng thì sẽ hiện "NAT traversal successful, IP shared" và kết nối P2P được khôi phục
  • Cách lách này được chia sẻ là đã xác nhận hoạt động với Deep Rock Galactic, Warhammer: Vermintide 2 và Far Far West, đồng thời cũng có thêm trường hợp áp dụng trên Street Fighter 6 và Melty Blood
  • Trong Melty Blood, do game dùng steam_api.dll, nên phải dùng steamwebrtc.dll thay vì steamwebrtc64.dll; nếu không có thư mục Binaries thì tệp được đặt vào cùng thư mục với steam_api64.dll
  • Một người dùng tổng kết rằng client Steam cũ sẽ thiết lập P2P trực tiếp bằng STUN, còn client mới thì vì một lý do nào đó không thử làm vậy, nhưng hiện vẫn chưa rõ chính xác thay đổi nằm ở đâu

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Ở đây có vẻ không hẳn là Valve làm hỏng, mà là xung đột ở Trung Đông đã lan sang không gian mạng, rồi ảnh hưởng tới cả người dùng dân sự
    Nhìn vào thời điểm và các quốc gia bị ảnh hưởng thì khá đúng như vậy, mà Trung Quốc cũng không phải nơi nổi tiếng về internet tự do
    WebRTC hoạt động như một đường thay thế, được mã hóa và cũng khó bị lạm dụng cho mục đích khác
    Trong khi đó STUN không được mã hóa, và bản thân giao thức này có thể bị dùng cho phản xạ/khuếch đại DDoS, nên việc nó bị vũ khí hóa hoặc bị chặn/phân tích theo thời gian thực làm hỏng kết nối cũng không có gì lạ

    • STUN/TURN trong WebRTC gần như đóng vai trò kiểu icanhazip
      STUN cho biết IP:cổng công khai, còn TURN cũng tương tự nhưng trả về IP:cổng được cấp động tại thời điểm truy vấn thay vì địa chỉ thực
      Client WebRTC gửi phản hồi STUN/TURN đó cho peer qua một đường tín hiệu ngoài băng như chat trên máy chủ lobby để thiết lập kết nối, đồng thời tạo mục trong bảng NAT ở cả hai phía như thể đó là kết nối đi ra ngoài
      Chỉ riêng STUN/TURN thì không thể tạo kết nối P2P, chúng chỉ là công cụ cần thiết cho WebRTC
    • Tôi từng thử làm một VPN P2P kiểu giống WireGuard trên WebRTC, và hiệu năng khá tốt, hơn 300Mbps
      Người dùng cuối không cần bận tâm tới vấn đề tường lửa hay khác biệt IPv4/IPv6, nên tôi nghĩ có thể điều chỉnh WebRTC cho game P2P thời gian thực hoặc mạng doanh nghiệp thay vì các giải pháp dựa trên IP
    • Có vẻ bạn đang hiểu ngược. WebRTC không hoạt động còn STUN thì có
    • Phần mềm mạng của chúng tôi cũng dùng P2P, nên vì thế đã triển khai toàn bộ theo kiểu xử lý trong băng thay vì dùng các cách phổ biến như STUN, TURN
      Các cách đó hay bị chặn và trong nhiều trường hợp cũng yếu về bảo mật
      STUN giờ đã có biện pháp giảm thiểu việc bị vũ khí hóa, nhưng vẫn là một giao thức tệ, và tôi không hiểu nổi vì sao cả STUN lẫn TURN đều hoàn toàn không có cách rendezvous nếu không có đường tín hiệu riêng. Đáng ra có thể thêm vào rất dễ
    • Chỉ cần IPv6, cùng với mã mạng được hiện thực tối thiểu bằng assembly, không có mấy tính năng ngách và phức tạp

  • Chuyện này chắc ai cũng biết rồi, nhưng điểm hay nhất của các thư viện và ứng dụng mã nguồn mở hoặc công khai mã nguồn chính là những bug report và thảo luận PR như thế này
    Rất ấm lòng khi thấy nhiều người cùng góp các triệu chứng họ gặp, cách lách qua, và giả thuyết về nguyên nhân

    • Thảo luận trên GitHub cũng từng chất lượng cao hơn nhiều hồi nền tảng này còn thiên về chuyên gia
      Dạo này tôi thường thấy nhiều cuộc thảo luận trôi theo kiểu thread reddit/4chan, nên lại có thêm một lý do để rời đi

  • Tiêu đề này không khớp với tiêu đề gốc của GitHub issue là "Major P2P issues in Israel and possibly other middle east countries"

  • Đây đúng là kiểu phỏng đoán hơi bừa của HN, nhưng nếu đọc hết GitHub issue thì sẽ thấy người dùng đang báo cáo STUN bị lỗi
    Tức là liên kết P2P không được thiết lập và bị thay bằng máy chủ relay có độ trễ cao
    Một số người dùng đã lách qua vấn đề bằng cách thay thủ công bằng dll WebRTC cũ của Valve, và tôi rất muốn đọc phần phân tích sau sự cố từ phía các dev Valve

  • Tại sao phần "in Israel and possibly other middle east countries" lại bị bỏ khỏi tiêu đề? Câu view à?

    • Hoặc cũng có thể là vì trên đời đã có quá nhiều thread tranh cãi Israel/Palestine, và họ muốn tránh để nó biến thành thêm một bãi chiến nữa
    • Nếu ở đây đủ lâu thì bạn sẽ biết rằng thêm cả cụm đó vào sẽ vượt quá giới hạn ký tự tiêu đề

  • Đây đúng là một bài gửi khá hụt hẫng, tôi không thể tin nó lại được upvote nhiều như vậy
    Có vẻ mọi người thấy chữ Valve trong tiêu đề nên nghĩ nó quan trọng, nhưng nội dung issue thực tế còn chẳng khớp với tiêu đề

  • Ban đầu đây là vấn đề P2P lớn ở Israel và một số nước Trung Đông, nhưng sau khi điều tra thêm thì lại trông giống vấn đề toàn cầu

    • Cho tới lúc này, "toàn cầu" ở đây có vẻ chỉ có Israel, Nga và Trung Quốc
      Cả ba đều không hẳn ưa thích tự do internet và đều có lịch sử dài về giám sát và kiểm duyệt, nên đây có thể là tác dụng phụ của chính sách mạng P2P nhằm khiến việc né tránh ISP kiểm duyệt trở nên khó hơn

  • Chuyện này có vẻ không phải vấn đề của Valve
    Các lỗi được báo cáo dường như chỉ xuất hiện ở những quốc gia quét và lọc kết nối rất gắt gao, và P2P nhạy cảm với kiểu can thiệp này
    SDR là một mạng relay được mã hóa, hơi giống onion routing
    Việc tác nhân xấu có thể phát hành game P2P rồi dùng chính game đó để liên lạc qua SDR là điều đã được biết rõ
    Không khó để hình dung tại sao ở những khu vực này người ta lại muốn kiểm tra loại lưu lượng đó

  • Tôi đang ở Trung Quốc, khoảng 3 tuần trước tôi có chơi game bên thứ ba thông qua game dev Spacewar của Steam, và có lẽ Steam P2P đã được bật, khi đó mọi thứ vẫn hoạt động bình thường

  • Chỉ nhìn tiêu đề thì trông như thể nó bị hỏng ở khắp mọi nơi