DigiLoog

発端は9月頭－－－

Lump of Sugarの新作『縁りて此の葉は紅に』のWebサイト公開辺りから、
オフィシャルサイトへの接続が悪くなっていて、新作確認が出来ていなかった筆者。
新作サイト公開直後のサーバダウンは良くある事(本当はあっちゃ駄目だが)なので、
毎度の如く夜中・早朝の人が少ない時間帯にアクセスして少しずつチェックしていたのだが、
ここの所、自鯖Proxy経由の場合のみ閲覧出来ない事に気付いた。

今まで普通にアクセス出来ていた中、不審に思いつつ自宅環境の調査をしていたのだが、
一向に解決出来なかったので、最後の手段・パケットキャプチャを実施してみた。

以前は「Lump of Suga」「QUINCE SOFT」で分割されていたのだが、一昨日辺りに統合された模様
ちなみに、筆者はQUINCE SOFTの新作『もののあはれは彩の頃。』は予約購入。

念押しではあるが、パケットキャプチャはグレーな側面もあるので悪用厳禁で。
今回は自分しか使わないテスト用自鯖Proxyを使ったので問題無かろう。

「なんでここまで本気出した」だって？
好きなゲームブランドのWebサイトに接続出来ないの悲しいじゃないですか！

と前置きは置いといて調査結果と解決方法から。
今回エラーになっていたのは、
恐らく「www.lumpofsugar.co.jp」の稼働しているレンタルサーバで実施している(筈の)、
セッション数制限に引っかかり、Webサーバ側でTCPコネクションをDROPされていた。
ただ、推測の域を出ないので真相は闇の中へ…

………

～ Phase.0 状況整理 ～

今回は、自鯖Proxy越しにアクセスが微妙に出来ないのが問題なので、
到達目標は『自鯖Proxy越しに “www.lumpofsugar.co.jp” にアクセスする』事とした。
また、自鯖環境をフル活用して被疑ポイントの特定を行う事に。

～ Phase.1 NW回線切分 ～

まず、真っ先に疑ったのはNW回線とMTS/MSSの設定ミス。
という事で、VPN越しに筆者の所有する下記回線からアクセスしてみたが、
どのキャリアでもProxy越しにアクセスすると全部アウトという事がわかった。

よって、NW回線は問題ではなくProxy有無が問題の可能性が強くなった。
その為、以後の切り分けは全てメイン回線(NTTPC)のみで実施した。

～ Phase.2 Proxy切り分け ～

次に自鯖のProxy構成を疑った。
“ns-lab BB”のアクセスProxyは、HAProxyをLSLB(ロードバランサ)代わりに下図のような構成になっている。
なので、TCPコネクション・SSLセッション維持で不具合が出たのではと疑った。

LBSBはアクティブ・スタンバイで確実に片寄せしているのでセッションは問題無し。
Proxy指定はPACファイルで実施しており、PAC配布用のWebサーバも稼働している。
PAC配布についてセッション維持はどうでも良いのでラウンドロビンで制御。
ProxyはX-Forwarded-ForのクライアントIPアドレス元に、
ソースハッシュで分散しているのでセッション維持の被疑対象外。

という事で被疑箇所を減らす為、HAProxyを外しProxy直指定でWebサイトの確認を行ったが、
Webサイトを見る事はやはり出来なかった。
状況整理と上記切り分けを実施した事で、Proxy直指定でも駄目な事から被疑箇所はProxyに限定化する事が出来た。

そもそも、対象がHTTPなのでセッション維持は必要無いだろうし、
上記構成のままソフマ○プでエ○ゲ購入とかも出来ているので、コネクション管理・セッション維持は問題無いだろう。

～ Phase.3 パケットキャプチャ ～

という事で、いよいよProxyが怪しくなってきた。
ここまで来たらパケット直視した方が楽なので、久々にtcpdumpとwiresharkを起動。
ClientPCとProxyの2箇所で同時に、
www.lumpofsugar.co.jpのindex.htmlを閲覧した時のパケットキャプチャを実施してみた。

[左]：Proxy未設定で直接Webサイト閲覧
[右]：LSLBを使わずProxyを直指定でWebサイト閲覧

キャプチャは、LocalCache・Cookieとかも全消去して環境を出来る限り揃えた状態で実施。
結果、なんとなく方向性の見える結果が出てきた。
今回重要なのは、右側のProxy利用時はTCP Retransmissionが出ている点。
ざっくり言うと、www.lumpofsugar.co.jpからACKが返ってこなかった為、TCP再送要求が発生していた。

コレが判ればしめた物。後はキャプチャ結果を解析していけば良い。
という事で同様のパケットキャプチャを数回実施して、3日程パケットをみつづけてみた。
結果、www.lumpofsugar.co.jpへ接続しに行った時のみ、次の特長が発生している事が判明した。

1. Proxy有無に関係無く「TCP Retransmission」が発生するがProxy越しの方が圧倒的に多い
2. Proxy無しの場合、最初にTCPコネクションを数発張った後、エラーが出つつもデータを受信している
   Proxy有りの場合、最初にTCPコネクションを20発位張って、データを取得しようとしている
3. Proxy有りの場合、HTTP/503、HTTP/504の応答が多かった

ここでなんとなく思い当たる節が。

以前、別件でTCPコネクション過多によるWebサーバ応答不能のデバッグをやった事があった。
その時は、Webサーバ側に仕込んであったIPアドレス毎のセッション数制限に引っかかり、
Webサーバ側で遮断・ACKも返さなくなった為、クライアント側ではパケットが途中で破損してしまい、
HTTP/503などエラーが表示されてしまう事例があった。

『今回もコレなんじゃ…？』と思い、クライアントPCの同時コネクション数を一時的に上げてみた所、
Proxy有りの場合と同じく、エラー状況を再現出来た。と、言ってもProxy有り程の顕著な物では無かったが…
ともあれ、状況の再現性を確認出来たので後はコレを解決出来る手段を見つけるだけとなった。

～ Phase.4 打開策検討 ～

次は「Proxy越しにアクセス出来る」様にしないといけないので、
ProxyでoutboundのTCPコネクション数をClientPC(Win10-1703)程度まで減らす制御出来るのか調査。
というのも、Proxyでは受信したデータを一度蓄積した後、
一気にTCPコネクションを張りに行っている(様な)挙動をしていた事から、
「IPアドレス・ドメイン毎のTCPコネクション数を制御出来れば何とかなるのでは？」と考えた為。

今回、物は試しで、Proxyは「Squid / Delegate / WinGate」の3種類、
OSは「Linux(CentOS7) / Windows(WindowsServer2012R2)」の2種類、
LinuxについてはkernelのTIME_WAIT時短設定なども実施してみた。

が力及ばず、自分の知識・技術では実現出来なかった出来なかった (´・ω:;.:…
自分がテストしたが出来なかったのは下記の通り。
Proxyに詳しい御方、やり方知っていたら教えて下さい…

• Squid
  [pipeline_prefetch on/off]
  [half_closed_clients on/off]
  [detect_broken_pconn on/off]
  [client_persistent_connections on/off]
  [server_persistent_connections on/off]
  　
• Delegate
  ※細かいオプション知らないので接続テストのみ。が、あえなく撃沈
  　
• WinGate
  ※そもそも使い方がよく判らないのでProxy越しに見れるかのみ。が、あえなく撃沈

～ Phase.5 ワークアラウンド ～

結局の所、自力では解決出来なかったので今回は諦めた (´；ω；｀)
と言いつつもワークアラウンドは必要なので、今回はProxyPACで制御する事にした。

Phase.2記載の通り前段に構えているProxyPACで、
『”.lumpofsugar.co.jp”ドメイン宛の通信は直接(DIRECT)取得』というルールを追加した。
ProxyPACに色々と記載するのは嫌なのだが、こんな事もあろうかとPAC構成にしておいて事なきを得た。

$ vi proxy.pac

-----

function FindProxyForURL(url, host){
  // Direct access for URL
  if ( dnsDomainIs(host, ".lumpofsugar.co.jp")){
    return "DIRECT";
  }

  // Default PROXY
  return "PROXY [[ProxyFQDN:PORT]]";
}

～ Phase.6 追加調査 ～

ここまでやって解決出来ないのは敗北感が凄いので、調べられる範囲内で情報を引っ張ってみた。
下記はInternet上から取得出来る内容なので、興味ある人は迷惑掛けない程度に調査してください。
ちなみに、筆者は中の人では無い事と、下記情報の正確性担保はしない事を宣言しときます。

• ドメイン：www.lumpofsugar.co.jp
• アドレス：124.146.200.148
• 鯖事業者：WebARENA Suite V1/V2

グローバルIPのAS番号、ドメインのネームサーバ情報、whoisの情報、
DNSのSPF登録情報、などを相関的的に分析した結果だが結構良い線行っている筈。

もし本当にWebARENAを使っているのならば、
ホストを共有している他サーバに引きずられるかもしれないし、
今回の様なコネクション断は仕方ないのかもしれない (´・ω・｀)

………

なんとも煮え切らない結果となってしまったが、技術で解決出来る(殴れる)所はなんとかしたい所。
他サイトで発生する事もあるだろうし、何か解決案が無いか長期的に探っていこうと思う。
今回のワークアラウンドを実施する事で、Lump of Sugar新作ページを見れたので一言。

「木那里もみじ」が可愛すぎる！　(*´Д`)ﾊｧﾊｧ

「ケモ耳＋セミロング＋ニーソ」と色々ぶっ込んできているが､
個人的には大歓迎です (｀・ω・´)
主題歌もKiccoさんだし発売が待ち遠しい。