TL;DR

長すぎて読んでられないよ！って人へ。

*.vrchat.cloudの名前解決をAAAAレコードではなくAレコードのみで行うように設定してください。万人向けの方法としてはhosts書き換えがあります。

VRChat ソーシャルバグ

ネットの噂によると、VRChatではIPv6接続有効時にRequest Inviteが使えないことがあるそうです。

私自身の環境では再現性が取れなかったため、伝聞での話ですが、どうやらソーシャル機能が使い物にならなくなる不具合があるそうです。

現象

IPv6有効な環境でVRChat上で

ソーシャル欄が更新されない
InviteやRequest Inviteが届かない

事象が発生するらしいです。

フレンドと軽く検証した結果、以下の事象が発生しました。(私は正常に動作している)

相手 --Invite--> 自分 : ○
相手 --ReqInv--> 自分 --ReqInvOK--> 相手 : ☓
自分 --Invite--> 相手 : ☓ 
自分 --ReqInv--> 相手 : ☓ 

考えられる原因

私はネットワークに詳しくない上に、自分の環境で再現性が取れなかったため正しいかどうかわかりませんが、Twitterで調べたり、フレンドと検証して、以下の答えにたどり着きました。

VRChat(特にCloudFlare)関係の名前解決もしくはルーティングが正常に行われていない。

Twitter上で流布されている対策の一つに、IPv6の通信を無効化すると改善するという話がありましたので、ほぼ確定でこれが原因だと思います。

しかしながら、VRChatユーザーの1人にすぎない私が、VRChat側の不具合を修正することはできないため、別の解決策を考えてみます。

既知の対処法では、すべてのIPv6を使った通信を無効化することとなり、インフラエンジニアとして負けだと思ったため、採用しません。

調査

では、調べてみましょう。

VRChatの通信相手を調べる

サーバとクライアント間での問題を調べるため、とりあえずVRChatが通信している相手を調べてみましょう。

コマンドプロンプトを起動し、netstatコマンドを使用することでパソコンが現在通信している相手を一覧表示することができます。

しかしながら、欲しいのはVRChatの通信先なため、絞り込まなければなりません。そこでfindコマンドを用い、プロセスID(PID)で絞り込んでみます。

PIDはタスクマネージャーの詳細タブで調べることができます。(起動毎に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>

結果を見ると、いくつか自身(127.0.0.1)に向けた通信がありますが、それ以外では

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

この2つのIPが誰のIPかを調べてみましょ

このIPをどの団体に割当られているかはwhoisで調べることができます。が、Windows 10にはwhoisコマンドが実装されていないため、

Windows Subsystem for Linux (WSL)を用いて調べることにします。WSLの有効化方法は割愛します。

[email protected]:~$ whois 35.241.52.229 | grep "OrgName"
OrgName:        Google LLC
[email protected]:~$ whois 2606:4700::6812:1a24 | grep "OrgName"
OrgName:        Cloudflare, Inc.
[email protected]:~$

ということで、35.241.52.229はGoogle、2606:4700::6812:1a24はCloudflareに割り当てられているIPということがわかりました。

今回、IPv6による通信が問題と思われるため、後者のCloudflare関係がおかしいと推察できます。

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

Wiresharkというパケットキャプチャを用いて、名前解決を覗いてみます。

オンラインゲームは当たり前ですが、外のサーバーと通信しています。もちろんこういったサービスでは固定IPを割り振ってもらって運用するものですが、ゲームにIPアドレスを直書きすることはまあ無いと思います。

もし、何らかの理由でIPアドレスを変更しなければならない場合など、アップデートを挟まなければなりませんし、IPアドレスを直書きしている場合、IPv6対応などがめんどくさそうなので。

なので、一般には公開しないドメインを使ってサーバーとの通信を行っている可能性が高いです。今回はそれを目論んでパケットキャプチャでDNSプロトコルのリクエストなどを覗いてみます。

私も今回初めてWiresharkを使用してパケットキャプチャを行ったので、もっと良い方法があるかもしれません。

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

ipconfig /flushdns

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

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

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

Wiresharkの使用法などはめんどくさいのと、まさかりが飛んでくるのが怖いので割愛します。

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

の順番で良いと思います。

後は適当にdnsプロトコルでフィルターを掛け、CSVで出力します。

では、DNSレコードを覗いてみましょう。

例によって、WindowsにはawkがないのでWSLを使用します。PowerShellを使えば高度なことができるんでしょうが、そこまでしてPowerShellを使いたくないので。

[email protected]:/mnt/c/Users/JO3QMA/Desktop$ grep "response" test.csv | grep "vrchat" | awk -F'\",\"' '{print$7}' | 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
[email protected]:/mnt/c/Users/JO3QMA/Desktop$

適当にVRChat関連は*.vrchat.*だろうと目星をつけてそれ以外を弾いています。

見たところ、以下のドメインに対して名前解決を試みたようです。

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

assets.vrchat.comはCNAMEでCloudFrontに別名がついているようです。今回のものとは関係なさそうなので、パスします。

残った2ドメイン

api.vrchat.cloud
pipeline.vrchat.cloud

に関してはAレコード及びAAAAレコードで名前解決が行われているようです。

次に、digコマンドを用い、DNSの正引きを行ってどのようなIPアドレスで名前解決が返されるか見てみます。

AレコードとAAAAレコードを見ます。grepは必要ない行を弾いてるだけなので気にしないでください。

[email protected]:/mnt/c/Users/JO3QMA/Desktop$ dig api.vrchat.cloud a | grep -v "^;" | grep -v '^\s*$' 
api.vrchat.cloud.       0       IN      A       104.18.26.36
api.vrchat.cloud.       0       IN      A       104.18.27.36
[email protected]:/mnt/c/Users/JO3QMA/Desktop$ dig api.vrchat.cloud aaaa | grep -v "^;" | grep -v '^\s*$' 
api.vrchat.cloud.       0       IN      AAAA    2606:4700::6812:1a24
api.vrchat.cloud.       0       IN      AAAA    2606:4700::6812:1b24
[email protected]:/mnt/c/Users/JO3QMA/Desktop$ dig pipeline.vrchat.cloud a | grep -v "^;" | grep -v '^\s*$' 
pipeline.vrchat.cloud.  0       IN      A       104.18.26.36
pipeline.vrchat.cloud.  0       IN      A       104.18.27.36
[email protected]:/mnt/c/Users/JO3QMA/Desktop$ dig pipeline.vrchat.cloud aaaa | grep -v "^;" | grep -v '^\s*$' 
pipeline.vrchat.cloud.  0       IN      AAAA    2606:4700::6812:1b24
pipeline.vrchat.cloud.  0       IN      AAAA    2606:4700::6812:1a24

ということで、

api.vrchat.cloud
pipeline.vrchat.cloud

に関してはAレコードもAAAAレコード共に同じIPに向いていることがわかりました。

複数のIPアドレスが列挙されている点については、DNSラウンドロビンというロード・バランシングの機能のひとつなので、どちらにアクセスして帰って来る結果は同じです。

結論

最初の仮定が正しいならば、

api.vrchat.cloud
pipeline.vrchat.cloud

これら2ドメインに対するIPv6通信をできないようにすれば良さそうです。

個人的に追記するならば、files.vrchat.cloudに対する通信も一度だけ確認し、AレコードとAAAAレコードが上記2ドメインと同じだったため、これも追加した3ドメインをどうにかしてやれば良さそうです。

対処法

ルーターを使用してAAAAレコードの問い合わせをrejectする

多分これが一番スマートな解決法です。

DNSのAレコードが書き換わっても何もせずとも対処できます。

問題点はそんな高度な設定をするためにはYAMAHAのRTXシリーズなど業務用ルーターが必要なことですね。

HMDと同じぐらいの値段で売ってるので買いましょう。そこら辺の民生品とは比べ物にならない安定度を誇ります。

DNSサーバーを建てる

*.vrchat.cloudのAAAAレコードを消したDNSサーバーを建ててやればよいです。

自宅サーバーをお持ちの逸般の家庭の諸氏には余裕でしょう。

問題点といえば、自宅サーバーを運用できるような人は業務用ルーターも持っていることが多いため、この手段より上記手段のほうが良いでしょう。

hostsを書き換える

hostsファイルを書き換える事により、DNSを見に行く前にIPを決め打ちしてやります。

管理者権限が必要となりますが、確実に今までの手段より楽です。

管理者権限をお持ちでない人はおかあさんにお願いしましょう。

C:\Windows\System32\drivers\etc\hostsに以下を追記します。

18.27.36  pipeline.vrchat.cloud
18.27.36  api.vrchat.cloud
18.27.36  files.vrchat.cloud

実行結果:

C:\Users\JO3QMA>netstat -ano | find "28884"
  TCP         127.0.0.1:52297        127.0.0.1:52298        ESTABLISHED     28884
  TCP         127.0.0.1:52298        127.0.0.1:52297        ESTABLISHED     28884
  TCP         127.0.0.1:52316        127.0.0.1:52317        ESTABLISHED     28884
  TCP         127.0.0.1:52317        127.0.0.1:52316        ESTABLISHED     28884
  TCP         192.168.1.25:51306     104.18.27.36:443       ESTABLISHED     28884
  TCP         192.168.1.25:51307     104.18.27.36:443       ESTABLISHED     28884
  TCP         192.168.1.25:51311     13.33.211.105:443      ESTABLISHED     28884
  TCP         192.168.1.25:52311     13.33.211.177:443      ESTABLISHED     28884
  TCP         192.168.1.25:52324     104.18.27.36:443       ESTABLISHED     28884
  TCP         192.168.1.25:52325     104.18.27.36:443       ESTABLISHED     28884
  TCP         [2400:4150:5363:3b00:e1f4:27f8:96da:2a57]:51322  [2404:6800:4004:826::200e]:443  ESTABLISHED     28884
  TCP         [2400:4150:5363:3b00:e1f4:27f8:96da:2a57]:51323  [2404:6800:400a:16::a]:443  ESTABLISHED     28884
  TCP         [2400:4150:5363:3b00:e1f4:27f8:96da:2a57]:51324  [2404:6800:4004:820::2003]:80  ESTABLISHED     28884
  UDP         0.0.0.0:9000           *:*                                    28884
  UDP         0.0.0.0:51116          *:*                                    28884
  UDP         0.0.0.0:60698          *:*                                    28884

うまいこと機能していると思いますし、VRChatは一応正常に遊べています。

2404:6800:400x::とIPv6で通信していますが、whois見る限りGoogleなので、問題ないでしょう。

なお、ここまで書いておいてアレですが、hostsに記載するIPアドレスには気をつけましょう。セキュリティ的なリスクを孕みます。

できる限り、自分で調べたIPアドレスを記載するようにしてください。

VRChat IPv6有効時のソーシャルバグ対応策

TL;DR

VRChat ソーシャルバグ

現象

考えられる原因

調査

VRChatの通信相手を調べる

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

結論

対処法

ルーターを使用してAAAAレコードの問い合わせをrejectする

DNSサーバーを建てる

hostsを書き換える

Further Reading

IPv6有効時にVRChatのソーシャルが更新されない件

保証期間外Valve Index RMAメモ

2023/05/04 雑記