VRChatのソーシャルバグについて

ネットの噂によると、VRChatのソーシャルがいつまで経っても更新されないバグがあるそうです。

vrchat.comの方は更新されるのに、VRChatの方は更新されないらしいです。

フレンドと軽く検証した感じ、以下の事象が確認されました。

相手 --インバイト送信--> 自分 : ○
相手 --リクイン送信--> 自分 --リクイン承諾--> 相手 : ☓
自分 --インバイト送信--> 相手 : ☓
自分 --リクイン送信--> 相手 : ☓

TL;DR

「この記事が長すぎて読んでられないよ！」って人へ。

VRChat側の間違ったIPv6ルーティング周りの実装によって、一部環境ではソーシャルが更新されないという不具合が発生しています。

一般に言われている「IPv6を無効化する」という方法は最悪レベルに良くない対処なので、実施しないでください。

C:\windows\system32\drivers\etc\hostsというファイルに以下を記述してください。(管理者権限で開いてください。)

104.18.27.36  pipeline.vrchat.cloud  # VRChat Social Bug Workaround.
104.18.27.36  api.vrchat.cloud       # VRChat Social Bug Workaround.

これより下に記述する内容は、仮定とそれの実証、対処法などです。

暇だったり、理屈が知りたい場合はどうぞ。

仮定: IPv6のルーティングがおかしい

自分の環境では再現しないため、これが確実な原因と言い切れませんが、Twitter(X)やフレンドの話をまとめると以下の答えが導き出されました。

VRChat(特にCloudFlareが担ってる部分)のIPv6の名前解決もしくはルーティングが正常に行われていない。

Twitterでよく流れてくるソーシャルバグ対策の一つに、「IPv6通信を無効化すると改善する」ということがあったため、この線が濃厚です。

しかしながら、IPv6通信を無効化することは昨今のIPv4からIPv6への移行の妨げにしかならないため、これ以外の方法を探してみます。

検証

机上で論理立てても正しいことが証明できないので、手を動かしてみましょう。

VRChat.exeの通信相手を調べる

仮定は「IPv6通信がおかしい」ですので、どのような通信がおこなれているかを調べてみます。

コマンドプロンプトにてnetstatコマンドを使うことで、パソコンが現在通信している相手を調査することができます。

欲しい情報としてはVRChat.exeが通信している相手だけなので、不必要な情報は削ぎ落としましょう。

そういった場合にはfindコマンドを用い、プロセスID(PID)で絞り込みます。

タスクマネージャーの詳細タブからVRChat.exeのPIDを調べることができます。(PIDは起動毎に変わります。)

taskmgr

PIDを調べた後、コマンドプロンプトで以下のコマンドを実行すると、その時点でのVRChatの通信先を調べることができます。

netstat -nao | find "PID"

実行結果

C:\Users\JO3QMA>netstat -nao | find "14776"
  TCP         127.0.0.1:56426        127.0.0.1:56427        ESTABLISHED     14776
  TCP         127.0.0.1:56427        127.0.0.1:56426        ESTABLISHED     14776
  TCP         127.0.0.1:56434        127.0.0.1:56435        ESTABLISHED     14776
  TCP         127.0.0.1:56435        127.0.0.1:56434        ESTABLISHED     14776
  TCP         192.168.1.25:57050     35.241.52.229:443      ESTABLISHED     14776
  TCP         [2400:4150:5363:3b00:8592:13c0:d8cf:3622]:56453  [2606:4700::6812:1a24]:443  ESTABLISHED     14776
  TCP         [2400:4150:5363:3b00:8592:13c0:d8cf:3622]:56455  [2606:4700::6812:1a24]:443  ESTABLISHED     14776
  UDP         0.0.0.0:63324          *:*                                    14776

C:\Users\JO3QMA>

実行結果を見てみると、いくつか自分自身のIPアドレス(127.0.0.1)に対して通信しているものもありますが、

それ以外には35.241.52.229と2606:4700::6812:1a24の443ポート(HTTPS)に向けて通信しているようです。

それぞれのIPアドレスの所有者を調べてみましょう。

このIPアドレスがどの団体が所有しているかはwhois情報を参照することで調べれます。

Windows 10にはwhoisコマンドが入っていないため、今回はWindows Subsystem for Linux (WSL)を用いて調べました。

jo3qma@Theta:~$ whois 35.241.52.229 | grep "OrgName"
OrgName:        Google LLC
jo3qma@Theta:~$ whois 2606:4700::6812:1a24 | grep "OrgName"
OrgName:        Cloudflare, Inc.
jo3qma@Theta:~$

調べた結果、35.241.52.229はGoogle、2606:4700::6812:1a24はCloudflareが所有しているIPアドレスだということがわかりました。

今回はIPv6の通信がおかしいという仮説ですので、後者のCloudFlare宛の通信に問題があるのではないかと考えられます。

パケットキャプチャして見てみる

雑な名前解決の話

ネットワークの領域に入ってくるのですが、一般にコンピュータ同士の通信にはIPアドレスがお互いに必要です。

しかし、IPアドレスは場合によって変更したりしますし、人間が覚えておくには厳しかったりします。

そのため、DNSという仕組みを使いドメイン名とIPアドレスを紐づけておき、ドメイン名からIPアドレスを正引きできるようにします。

例えば、google.comは172.217.25.174に紐づいており、google.comをアドレスバーに打ち込むだけで172.217.25.174というIPアドレスのサーバーにアクセスすることができます。

この仕組みを、名前解決と呼びます。

様々なインターネットを用いたサービスの内々の通信にもこのDNSの仕組みは使われており、

Twitter APIならばapi.twitter.com、Google APIならばwww.googleapis.comといった感じです。

VRChatも例外ではなく何かしらの通信をする際にこういったDNSを使っているものと考えられるため、調べてみます。

パケットキャプチャで名前解決のパケットを調べる

Wiresharkというパケットキャプチャができるソフトを用いて、名前解決に関する通信を覗いてみます。

Wiresharkはあまり使ったことがないため、もっと良い調査方法があるかもしれません。

パケットキャプチャを開始する前に、以下のコマンドをコマンドプロンプトで実行しておきます。

ipconfig /flushdns

このコマンドは、PC内のDNSキャッシュを削除するものです。

通常は以下の順で名前解決を試みるのですが、PC内のDNSキャッシュがある場合は3番目以降に問い合わせないため欲しいパケットがキャプチャできません。

なので、削除しておきます。

hosts
PC内のDNSキャッシュ
ルーター内のDNSキャッシュ
ISPのDNSサーバー

今回は以下の手順で調査を実施しました。

DNSキャッシュのクリア
Wiresharkでパケットキャプチャ取得開始
VRChat起動
VRChatで任意の時間遊ぶ
Wiresharkでパケットキャプチャの取得を終わる

パケットキャプチャを取得した後、DNSプロトコルでフィルターをかけ、CSV形式で出力しました。

この状態では、パケットキャプチャ取得中のすべてのDNSクエリの通信が時系列に並んでいる状態のため、欲しい情報を絞り込んでみます。

こういったテキストファイルの解析には、AWKを使うと便利です。

VRChat関連のドメインは*.vrchat.*だろうと目星をつけて、それ以外のドメイン名を弾いています。

jo3qma@Theta:/mnt/c/Users/JO3QMA/Desktop$ awk -F'\",\"' '/response/&&/\.vrchat\./{print$7}' result.csv | awk '{print$6,$7,$8}' | sort | uniq -c | sort -r
api.vrchat.cloud A 104.18.26.36
api.vrchat.cloud A 104.18.27.36
api.vrchat.cloud AAAA 2606:4700::6812:1a24
api.vrchat.cloud AAAA 2606:4700::6812:1b24
assets.vrchat.com CNAME d14hwloucscbyy.cloudfront.net
pipeline.vrchat.cloud AAAA 2606:4700::6812:1b24
pipeline.vrchat.cloud A 104.18.27.36
pipeline.vrchat.cloud A 104.18.26.36
jo3qma@Theta:/mnt/c/Users/JO3QMA/Desktop$

結果を見る限り、以下のドメインに対して名前解決を試みたようです。

api.vrchat.cloud
pipeline.vrchat.cloud
assets.vrchat.com

なお、assets.vrchat.comはCNAMEレコードが指定されており、CloudFrontというAWSのCDNへ向いているようです。

以下の2つのドメインに関してはAレコード及びAAAAレコードが指定されており、それぞれ名前解決を試みられているようです。

api.vrchat.cloud
pipeline.vrchat.cloud

~~この結果に出ていませんが、予備調査中にfiles.vrchat.cloudのDNS問い合わせを確認しました。~~

(知らん間にCloudFrontへのCNAMEになってました)

ということで、VRChatは上記2ドメインに対し内部で通信を行っていることがわかりました。

自分の環境でソーシャルバグが発生していないためこれ以上の調査は実施できませんので、仮定が正しいとして進めます。

対処法

IPv6周りのルーティングがおかしいと考えられるため、IPv6ではなくIPv4を使ってアクセスするようにしてやれば良さそうです。

ドメインの宛先調査

IPv6周りのルーティングがおかしいと考えられるため、IPv6ではなくIPv4を使ってアクセスするようにしてやれば良さそうです。

方法はいくつかありますが、最善とは行かないまでも簡単に設定ができて影響が少ない方法として、hostsファイルを使うという方法があります。

hostsファイルに記述

hostsファイルにIPアドレスとドメイン名を記述することで、強制的にドメイン名へのアクセスを指定したIPアドレスに向けることができます。

IPアドレスを指定しなければならないので、指定するIPアドレスを調べてみます。

ドメインのDNSレコードを参照する方法にdigコマンドというものがあります。

欲しい情報はIPv4なので、Aレコードを調べると良いです。

jo3qma@Theta:~$ dig A api.vrchat.cloud +short
104.18.27.36
104.18.26.36
jo3qma@Theta:~$ dig A pipeline.vrchat.cloud +short
104.18.27.36
104.18.26.36
jo3qma@Theta:~$

api.vrchat.cloud
pipeline.vrchat.cloud

は同じIPv4アドレスに向いていることがわかりました。

複数のIPv4アドレスが設定されている理由としては、DNSラウンドロビンというアクセス分散の技法の一つです。

どちらにアクセスしても返される結果は同じものです。

ではhostsに記述しましょう。

C:\Windows\System32\drivers\etc\hostsにhostsファイルがあるので、適当なエディター(メモ帳でも可)で管理者権限を使って開き、下記を追記します。

104.18.26.36  pipeline.vrchat.cloud  # VRChat Social Bug Workaround.
104.18.26.36  api.vrchat.cloud       # VRChat Social Bug Workaround.

もしくは

104.18.27.36  pipeline.vrchat.cloud  # VRChat Social Bug Workaround.
104.18.27.36  api.vrchat.cloud       # VRChat Social Bug Workaround.

保存すれば、再起動せずとも次回アクセス時からこのIPアドレスを使用します。

※ このファイルに記述するIPアドレスは信頼できるものを使用してください！
不正なサーバーに接続させられる可能性があります！

その他対処法

これらの対処法を実施できるような聡明な諸氏は例示せずとも実施できると思うため、述べるだけにしておきます。

DNSサーバーを構築し、上記2ドメインのAAAAレコードを握りつぶす。
ルーター側で上記2ドメインのAAAAレコードを握りつぶす。(業務用のルーターとかだとできる)

DNSサーバー構築するのはちょっと手間がかかるのでルーター側でいい感じにしたいですよね。

YAMAHAのRTXとかNECのIXだといい感じにできるらしいです。Ciscoとかだとどうなんだろうね。

この項目について

ヤマハギガアクセスVPNルーター RTX1220
ヤマハ(YAMAHA)
Amazonで見る

おわり

フレンドもこれで改善したと言ってるので、再現はせずとも大筋は正しそうです。

IPv6、何かと悪にされがちだけど間違ったネットワーク設定が原因なだけなので、IPv6自体を無効化しないでね！！！

インフラエンジニアからのお願いだよ～！！

あと、hostsに記述する内容は定期的にアドレスとかが変わってないか確認してね。；；

たまに宛先が変わっていることもあるので・・・！