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

Last modified: 2018-04-09

DNS 関連の作業はひととおり終わって、WordPress サイトの構築もクライアントの確認だけを残している。ということで、DNS を切り替える前から起きていたネットワーク関連の問題を片付けなくてはいけない。実際、自分で使っていても困ることが多々ある。

問題を整理すると、こうだ。(A1) 自社のウェブサイトにアクセスするのが 30 秒くらいかかる、(A2) メールの送信に 30 秒くらいかかる、(A3) 自社のウェブサーバ(SAKURA のマネージド・サーバ)へ ssh でログインするのに 30 秒くらいかかる。これに対して、(B1) 自社のウェブサイトで 500 などのエラーだったら即座にエラーページが表示される、(B2) メールの受信は即座にできる、(B3) 自社の他のウェブサーバ(SAKURA の専有サーバ)へ ssh でログインするのも即座にできる(これは、sshd の設定で UseDNS を無効にした)。そして、ping はどのサーバもレイテンシが遅延することはない。これだけなら、暗号化通信を使っている場合にだけ問題が起きているように見えなくもないが、コーポレートサイトの場合は 404 Not Found をわざと発生させるとエラーページは即座に HTTPS で返って来るので、HTTPS で通信しているからというわけでもなさそうだ。それに、ssh は専有サーバなら /etc/ssh/sshd_config で UseDNS=no を有効にすると即座にサーバへ接続できるようになったので、ssh での通信そのものに何か問題があるわけでもなさそうである。もちろん DNS がらみも疑って、Google の Public DNS や OpenDNS あるいはもともと使っていた USEN(アルテリアネットワークス)の DNS も切り替えてみたが、結果は同じである。

https://www.ourdomain.co.jp/index.html(遅い)

https://www.ourdomain.co.jp/hogehoge.html(速い 404 のリクエスト)

https://www.ourdomain.co.jp/test.php(遅い phpinfo() だけ書いたページ)

https://www.ourdomain.co.jp/test.html(速い 単なるテキストだけ書いたページ)

という結果なので、最初は PHP が遅いようにも見えたのだが、そうでもないようだ。実際、スマートフォンで PHP のページにアクセスすると問題なく速い。よって、これは明らかに当社の社内ネットワークの問題だと思う。

以前に書いたように、当社のネットワーク構成を概略で示すと、

[ルータ (YAMAHA)] - [UTM (Fortinet)] - [スイッチ (hp)] - [スイッチ (HanDreamnet)] - [クライアントマシン]

となっている。この中で、全ての社員のクライアントマシンで何らかの遅延が報告されているため、僕のマシンだけの問題ではなく、クライアントマシンが原因という可能性は消える(セキュリティソフトも何種類かあるし、僕のマシンは Active Directory からは切り離してある)。

[ルータ (YAMAHA)] - [UTM (Fortinet)] - [スイッチ (hp)] - [スイッチ (HanDreamnet)]

次にスイッチも、全てのポイントで同じ問題や障害が起きているとは考えにくいし、HanDreamnet のスイッチはもともとフィルタリングに癖があって僕は使っていなかった。また、hp の L3 スイッチが故障しているなら更に深刻な通信障害が起きている筈なので、これも違うと判断した。

[ルータ (YAMAHA)] - [UTM (Fortinet)]

ということで、ルータ(YAMAHA RTX-3000 という、かなり古い機器)か UTM(Fortigate)の可能性が高いと考えた。その検証として Wireshark を使ってみたところ、SAKURA のマネージド・サーバで運用しているメールサーバから SMTP でメールを送信したパケットの記録では(ログの内容は大半を削ってある)、

(1) 2018-03-22 14:04:31.540193 - DNS - *****.sakura.ne.jp

(2) 2018-03-22 14:04:36.538281 - Fortinet_6d:6e:18 - Pegatron_03:c6:a5 - ARP

(3) 2018-03-22 14:04:51.278064 - SMTP ESMTP Sendmail

のように ARP のやりとりで時間がかかっている。その他、Wireshark で同じサーバへ ssh でアクセスした場合でも、"tcp.analysys.flags" フィルタでおかしな通信だけを拾い上げると、[TCP Keep-Alive ACK] の山が出てくる。ともかく、何か異様な量のやりとりが無駄に発生しているとしか思えない。

とりあえず、本日の調査はここまでで、あとは大塚商会さんへログを確認してもらってコメントをもらうことにした。他にも、6 TB の外付け HDD が認識できなくなって大騒ぎになっているのを、とりあえず USB ケーブルを挿し直しただけで復旧させたり、やることは多い。

[追記:2018-03-23] 本日も朝からネットワークの調査をしていた。なんと、目の前にいる人のマシンではメールの送信に全く遅延がなく問題ないことが分かった。Windows でも Mac でも Linux のマシンでも同じ問題が起きているので、これは個々のマシンの問題ではないのだろう。しかし、どうして一部のマシンだけ問題がないのか。特別なハブを使っているわけでもないし、そのマシンだけが Active Directory 配下だとか SkySea のクライアントが動いているといったわけでもない。

MTU を調べたら、なんと 970 なんて値で、ディフォールトの 1500 だとパケットを断片化できていないらしい。ただ、MTU を 970 に変更しても、コーポレートサイトへのアクセスは遅いままだ。ただ、こういうことを色々とやっているあいだに、最初からアクセスできている Google+ とかの表示スピードがどんどん上がってきている。これは、何の副作用なのかは分からないが、良いことなのか。そして先に書いたように、メールの送信遅延が起きていないマシンがあったので、Wireshark でパケットを取得した。このほか、そのマシンは Active Directory にぶらさがっているので、AD サーバの DNS にこちらの設定を合わせてみたり、IPv6 がおかしいという意見もあるようなので無効にしてみたが、やはり改善しない。同じ社内でも問題のないマシンがあったというのは、これはちょっと更に難しくなってきたような気もする。

次に、レジストリで TCPACKFrequency が設定されていたので、キーを削除したが、これも効果がなかった。

netsh interface tcp set global autotuninglevel=highlyrestricted

も効果がない。

夕方になると、復元ポイントでシステムを直前の Microsoft Update がかかる前に戻したら、再起動とエラーを繰り返して Windows が起動しなくなった。ディスクのエラーを検査し始めて、その後もセーフモードですら起動しなくなったため、復元ポイントで戻す前の最新の復元ポイントへ復元するという奇妙なことをやると、ようやく復旧した。その間にも、受託案件で追加の作業やテスト公開用の修正作業などが入っていたのだが、Windows が起動しないのではどうしようもない。復旧を待ちながら、最悪の場合は倉庫から余ったマシンを出してきて間に合わせの環境で作業するしかないのだろうかと想像してみたが、Keepass Password Safe にサーバのアクセス情報があって、バイナリファイルを開くためのキー・ファイルはどうするのかという問題がある。こういう場合には、やはり一箇所に鍵を置くよりも秘密分散を使った方がいいんだろうかと思う。

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

冒頭に戻る


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

Google+ Twitter Facebook