2018年03月14日に初出の投稿

Last modified: 2018-03-14

ネットワーク周りのトラブルと思われる事態は、対処療法なのか根本的に解決したのか判断するのも難しい。まだまだ勉強なり経験の足りないところだと思う。CCNA のテキストからやりなおしてもいいくらいだ。なお、この Note は後日に進捗なり結論を追記すると思うので、ひとまずは暫定の報告として書いておく。

さて昨日の Note で書いたように、昨日は情報セキュリティ委員会の会議をやって、数日前から一部のサイトの表示が異様に遅くなったという報告が上がった。確かに、一部のサイトを始めとして、ssh や ssh over scp でのアクセスも遅い。サイトは一部だが、ssh は全てのリモートサーバに対して認証が30秒くらいかかるようになってしまった。しかし他方で、ChatWork や Google へは快適にアクセスできる。また、同じサイトへ、会社のネットワークと自分のスマートフォンのネットワークでアクセスしてみると、やはり会社のネットワークを使ったときだけ異様に遅い。よって、社内のネットワーク環境だけの問題だと分かる。後で書くが、ISP(アルテリア)管内の通信は traceroute だけを見る限りは問題ないようなので、まずは WAN 側とやりとりする箇所までに何か問題が起きていないかどうかを調べなくてはならない。

「さくらインターネットのコンパネ vs. 初期サブドメイン」という比較では、コンパネへのアクセスは圧倒的に速いが、初期サブドメインは表示されるまでに30秒ほどかかる。「jpn.nec.com vs. hitachi.co.jp」では、日立製作所のサイトが異様に重い。しかし、アドレスバーに URL を入力してアクセスするとタブに「日立製作所」というタイトルは出てくるので、メタ情報は即座にレスポンスを得ていることが分かる。そして、日立さんのサイトについては Ghostery でブロックしているトラッカーを全て許可(サイトを「Trusted」に登録)したら、表示は劇的に改善された。しかし、当社のコーポレートサイトを移設する SAKURA のマネージドサーバで割り当てられた初期サブドメインは、外部のアクセスは Google Analytics しかないのだが、それを許可しても表示スピードは改善されず、やはりコンテンツが表示され始めるまで30秒ほど待たなくてはならない(いちどページが表示され始めると速い)。この場合も、当社のサイトで使っている共通の TITLE タグの内容は即座にタブへ表示されるので、DNS の問題(そもそもリクエストがサーバに届いていないかレスポンスが全く返らない)でもないだろう。しかし例外も多々あり、天牛堺さんのサイト www.tengyusakai-shoten.co.jp は、タイトルタグの中身すらレスポンスされないまま止まる。では、ページがレンダリングされ始めるまでの数十秒(あるいは ssh でサーバへアクセスする場合は認証を通るまでの数十秒)に何が起きているのか。ウェブサイトの場合は必ずしも HTTPS ではないから、暗号化通信のためのシェイクハンドで止まっているというわけでもないらしい。

さて、最初に疑うべきは、しばしば自前の証明書でプロキシのようにシェイクハンドを代行するときにエラーを起こしやすい ESET Internet Security だが、全ての機能をいったん無効にしても状況は改善しない。逆にプロトコルフィルターで遅いサーバの IP アドレスやホスト名や FQDN を足しても同じだった。SSL や暗号化通信だけで遅いわけでもないので、これはひとまず除外する。

次に Scalable Networking Pack のような、Microsoft がこっそり実装しているマイナーな機能(でもネットワークのパフォーマンスに大きな影響を及ぼす可能性がある)だが、これをコマンドプロンプトで無効にしても、特に状況は変わらなかった。

通信プロトコルごとに原因が違うという可能性はあるから、まず ssh だけを見てみると、オンラインで暫く調べていたのだが、ssh の認証が遅い場合の対策として書かれているページの殆どが、アクセス先のサーバで ssh デーモンの設定を変更できるという前提でものを書いており、全く参考にならないことが分かった。そんなことができるくらいなら、ネットワークについてはともかく、我々のようなサーバ管理のプロはとっくにやってる。だいたい、何の通知もなしに客のサーバの ssh_config ファイルとかをサーバ会社が勝手に改変するとかありえないのだし、全てのリモートサーバがそれ以外の事情で勝手に設定ファイルが書き換えられて遅くなったのなら、もうこれはサーバのアクセス権限を奪われて設定を書き換えられている可能性を考えなくてはいけなくなる。

そして traceroute しろと書いているサイトも多いので、試しに「特定の遅いサイト」の一つである、当社が SAKURA で借りているマネージドサーバの初期ドメインを traceroute してみると以下のような結果だった。

1 <1 ms <1 ms <1 ms 192.168.1.1(これはデフォルトゲートウェイ)

2 <1 ms <1 ms <1 ms **

3 <1 ms <1 ms <1 ms **.ftth.ucom.ne.jp [**]

4 1 ms <1 ms <1 ms **.ftth.ucom.ne.jp [**]

5 <1 ms <1 ms <1 ms **.ftth.ucom.ne.jp [**]

6 1 ms <1 ms <1 ms **

7 <1 ms <1 ms <1 ms **.ftth.ucom.ne.jp [**]

8 * * * 要求がタイムアウトしました。

9 * * * 要求がタイムアウトしました。

10 * * * 要求がタイムアウトしました。

11 * * * 要求がタイムアウトしました。

12 * * * 要求がタイムアウトしました。

13 * * * 要求がタイムアウトしました。

14 * * * 要求がタイムアウトしました。

15 25 ms 25 ms 25 ms **.sakura.ne.jp [**]

USEN 管内は問題なく通信が遅滞なく通過している。しかし、これはウェブページをリクエストしたときのレスポンスではなく、 traceroute コマンドに対するレスポンスなので、HTTP 通信の turnaround time とは殆ど無関係と言ってよく、traceroute のログでは「要求がタイムアウトしました」に相当するポイントで遅くなってように見えるが、ウェブページのリクエストでも同じ経路で遅延しているという推定をするのは軽率である。よって、実は traceroute コマンドなんて幾ら使っても、ウェブサイトへのアクセスが不調となる原因は分からないのだ。

ということで、やはり基本的な調査として Wireshark でパケットを見ることにした。ssh で SAKURA の専有サーバへアクセスしたときのログでは、

[No.: 28] [Datetime: 2018-03-13 16:05:39.801322] [SAKURA IP] [MY PRIVATE IP] [Port: 22→9375] [TCP] [Info: ACK Seq=3622 Ack=2419 Win=19072 Len=0] [Lengh: 60]

[No.: 29] [Datetime: 2018-03-13 16:06:07.793323] [SAKURA IP] [MY PRIVATE IP] [Port: 22→9375] [SSHv2] [Info: Server: Encrypted packet (len=128)] [Length: 182]

といったように、認証のレスポンスが返って来るまでに30秒くらいかかっている。

ただ、専有サーバの方は自分でリクエストを受ける側で ssh を設定できるサーバだから、遅いときの対策として知られている幾つかの設定を追加してみた。

sshd_config -> UseDNS=no

ssh_config -> AddressFamily inet と GSSAPIAuthentication no を追加

こうして # service sshd restart で、アクセスは劇的に改善された。ということは、ウェブサイトへのアクセスとは別の原因になっている可能性もある。が、UseDNS を切って改善したかもしれないということは、ブラウザでのアクセスも DNS が影響しているような気もする。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook