或るネットワーク環境のトラブルシューティング

河本孝之（Takayuki Kawamoto）

Contact: takayuki.kawamoto (at) gmail.com.

ORCID iD iconORCID, Google Scholar, PhilPapers, about.me.

First appeared: 2018-11-19 16:33:20,
Modified: [unknown for the future],
Last modified: [unknown for the future].

はじめに

本稿は、やや腰砕けの結末にはなりますが、今年の前半にあった、所属企業でのネットワーク接続の問題を解消するまでに何をしたかという経緯を説明しています。後半の経緯は、ちょうど母親が入院した時期と重なったため、記録は残していましたが記事を書く余裕はありませんでした。その母親も10月に亡くなり、既に四十九日も滞りなく終わりましたので、当時の様子を思い出しながら、こうして記事としてまとめなおしてみた次第です。大半は全く見当はずれの対策をあれこれとやっているので、ネットワーク通信の技術者には参考にならないと思いますが、似たような状況に置かれた方の参考になれば幸いです。

要求と要件

当社では、自社サービスのウェブサイトで使うウェブサーバやデータベースサーバをデータセンター（以後「IDC」）でハウジングしてもらっていました。そして、サーバの管理・運用を委託しているベンダーさん（以後「Q 社」）のネットワーク・セグメントに間借りさせてもらっていたのです。つまり、Q 社の FW や LB の配下にぶら下っていて、IDC から Q 社に対して供給される帯域を分けてもらっていることになります。もちろん、当社のサイトで使った転送量は独立に計測されており、たいていの IDC では「最大瞬間風速」で課金されるので、一時的にアクセスが増大すれば比例して従量課金の金額も上がります。当社のサーバ・マシンは WEB + DB の合計で 20 台くらいあって、企業としてはごく標準的な、減価償却資産の法定耐用年数である５年おきに買い替えては、それなりの出費を続けていました。その間にも故障などで HDD を交換することは何度かありましたから、少なくともコールド・スタンバイのハードウェアも余分に用意していたため、ハードウェアにかかる費用は更に多くなります。これに加えて、もちろんサーバやネットワークやアプリケーションの管理・運用を委託している Q 社にはメンテナンス費用を支払っていましたし、それ以外の様々な雑務、例えばメールアカウントを作成してもらうとか、ドメインを再登録する申請を出してもらうとか、あるいは SSL サーバ証明書を更新してインストールしてもらうといった費用がかかります。（下記の模式図で「旧」と表記してある経路に相当する。）

社内からコーポレートサイトへ接続する模式図

ということで、そろそろハードウェアの買い替えとかメンテナンスにかかる費用を抑えたいという要求が出てきました。もちろんサーバ・マシンなどの買い替えにかかる費用が合計で数千万円だとしても、多くの企業ではリースを組むので、一度にそれだけを出費するわけではありません。しかし、そうしたリースが件数として増えると継続して負担がかかるため、好ましくないのは事実です。このため、サーバ・マシンの耐用年数が近づいてきたタイミングで、そろそろクラウド・サービスへ切り替えることとなりました。クラウド・サービスだと、経理上はサービスの利用として費用を計上し、減価償却などは関係なくなります。SaaS 上で公開する自社サービスの開発費用だけが「ソフトウェア」として別に計上されることになって、クラウド・サービスに切り替えると経理上の手間は少なくなるというのが一般論です。ただし、プラットフォームの OS やネットワークで発生したインシデントに対して自社側では何の対策もとれない（クラウド・サービス業者へ依存する）といった別のデメリットがあります。

ともあれ、こういう事情があって IDC のハウジングから当社のサーバ・マシンを全て撤去することになりました。そして、当社のコーポレートサイトを運用しているサーバ・マシンも、同じセグメントに所属しているため、どこかへ移さなくてはならないという事案が発生しました。なお、コーポレートサイトに関わるサーバ・マシンは、ウェブサーバとメールサーバとを兼ねる機器と、データベースサーバの機器という二台構成になっています。本稿では、これらを「コーポレート・サーバ群」と呼び、個々のサーバは「コーポレートのウェブサーバ」とか「コーポレートの DB サーバ」などと呼びます。サーバ・マシンで動作する httpd や postfix のような「サーバ・プロセス」や「サーバ・ソフトウェア」と混同しないようにしてください。そして、初めは「クラウド」というフレーズだけを聞いていたので、幾つかのサービスを検討してみましたが、今回の IDC からの撤収事案を仕切っている役員と話をしてみると、要するにコストダウンしたい（財務上も B/S に大きな影響を与えないようにプラットフォームを維持したい）というのが目的だったため、「クラウド」というフレーズには固執しなくてもいいと判断して、幾つかの要求を洗い出しました。

  1. IDC つまり Q 社の管理下からコーポレートサイトを移設する。
  2. Q 社は当社が運営する自社サービスをクラウドへ移設する作業にかかりきりとなるため、コーポレートサイトの移設は僕だけで作業を完結させる。
  3. ランニングコストは、現状のサーバ・マシンの買い替え費用, メンテナンス費用, 帯域利用料金よりも抑える。
  4. サーバのメンテナンスについて、今後は Q 社や僕の工数を使わないようにする。

以上から要件を導くと、4. からは VPS や専有サーバは却下ということになり、それどころか当初のクラウドサービスも却下せざるをえないと分かりました（クラウドサービスは、ウェブサーバとしてだけ使うなら実質 VPS や専有サーバと同じであり、自分で OS をセットアップしたりメンテナンスしなければなりません）。よって、レンタルサーバか、いわゆる「マネージド」と呼ばれる専有のレンタルサーバが選択肢として残ります。Q 社の工数を、移設作業やその後の運用フェイズでも使いたくないというコストの問題が大きいので、あとはコストとなるわけですが、レンタルサーバとマネージド・サーバの比較では大きなポイントがあって、マネージド・サーバを選ぶしかないという結論になりました。そのポイントというのは、「メーリングリストを幾らでも増やせるかどうか」です。共有のサーバを利用するレンタルサーバの場合は、スパムを送信されてホスト名や IP アドレスがブラックリストに掲載されると、他の契約者にも影響があるため、もともとメーリングリストの作成数に制限がかかっていて、多いところでもせいぜい 30 個くらいが限界です。当社では、事業部門別、プロジェクト別、案件別などで 50 以上のメーリングリストを運用していて、移設するためにどれかを減らすというわけにもいかず、メーリングリストの作成数に限界があるレンタルサーバは選べません。そして、マネージド・サーバのサービスを提供しているサーバ会社は数多くありますが、もちろんサーバ・マシン自体が専有ですし、プラットフォームの管理を代行してもらうわけですから、レンタルサーバよりはコストがかかります。ということで、僕自身が 15 年以上はお付き合いしている SAKURA Internet（どうしてこういう書き方をするのかは、僕の Note を参照してください）で借りることとしました。他にもマネージド・サーバを提供している会社さんは幾つもありますが、マネージド・サーバのプランではサーバの運用の大半をサーバ会社に任せることになるので、実績、それから root 権限をもたないユーザの範囲で可能なことが明確に分からない会社さんのサービスを選ぶのは、それなりにリスクがあります。（サービスを使い慣れていて、実績としても分かっているのであれば、SAKURA Internet でなくても問題ないと思います。）

冒頭に戻る

付随する状況

そして、今回は上記に付随する状況として、ドメインの管理を Q 社から当社に引き取るということも加わりました。とにかく Q 社に対して支払うメンテナンスや運用費用が大きくなりすぎているため、少しでもランニング・コストを減らしたいという事情がありますから、ドメインの運用は僕の部門（「部門」とは言っても僕一人ですが）で引き受けることとしました。対象となるドメインは以下のとおりです。

他にも幾つかのドメインが関わっていますが、とりあえずこれら三つで話を進めます。company.org, company.biz は、どちらもテスト用にも使っているドメインなのですが、company.org はドメインつまり DNS を Q 社が管理しているため、サブドメインの追加といった細々とした作業でも発注して依頼しなくてはならず、最初のうちは company.org だけでテストサイトを作って広告代理店案件のステージングに利用していたのですが、５年くらい前からムームードメインで新しく company.biz を取得し、ステージング用途などで緊急に（それこそ朝言われて昼までにとか）テスト領域を用意するといった、いかにも広告代理店系列のウェブ制作会社にありがちな突貫作業に対応できるようにしたわけです。もちろん、company.biz のサブドメインの大半は、既に SAKURA Internet で借りている専有サーバ（僕が root を持っていて全権を握っているサーバ）でも数多くのテスト領域を運用していますが、その専有サーバを借りる前は IDC にあるコーポレートのウェブサーバに DNS を向けて VirtualHost を設定し、数多くのサブドメインを運用していたというわけです。

これらのドメインの管理・運用を全て当社（つまり僕）が引き受けることも、今回のプロジェクトに入ってきたので、Q 社に依頼して、company.co.jp はレジストラ移管の承認作業をしてもらい、company.org はレジストラ移管に必要な認証コードを知らせてもらって、こちらで移管作業を進めました。また、Q 社からは company.co.jp と company.org で設定している DNS のゾーン・ファイルをもらって（どちらのドメインも、Q 社が建てている DNS サーバを primary, secondary の NS として使っていたため）、その内容を当社で使っているムームードメインのムームー DNS あるいは SAKURA Internet の DNS サーバ設定に追加しなくてはなりません。その際に、ゾーン・ファイルの設定内容を精査し直して、現在は使っていないサブドメインの情報は削除したり、幾つかの変更を加えました（もちろん A レコードの飛び先を新しい IP アドレスに変更するのは自明です）。

冒頭に戻る

移設作業

社内からコーポレートサイトへ接続する模式図

３月末の時点で、既にコンテンツやメールサーバの移設そのものは完了して、移設先のサーバで（少なくともメールサーバの）運用は始まっています。そして、この移設作業から始まった幾つかの不具合の記録が本稿の主旨なので、まず移設作業として実際にやったことを箇条書きでまとめます。冒頭で挙げた模式図では、赤枠で囲んであるのが IDC の旧デプロイメント、そして青枠で囲んであるのが（たぶん SAKURA のデータセンター内ではもっと複雑だと思いますが）SAKURA Internet での新デプロイメントとなっています。

  1. 移設先のサービスを選定し、起案する。（「さくらのマネージドサーバ SSDプラン」、初期費用＋初回は二ヶ月分の利用料金がかかるので、税込みの合計で98,280円、月額の費用は税込みで19,440円）
  2. 経営会議で全ての事業部門にサーバ移設を告知して了承を得る。
  3. 移設に関わる費用（サーバとドメイン関連）の稟議を通す。
  4. マネージドサーバの契約を申し込み。経理に初回請求金額の振り込みを依頼。
  5. company.co.jp のレジストラ移管を申請、company.org の認証コードをもらってレジストラの移管を申請。
  6. 経理がマネージドサーバの初回請求金額を振り込み。
  7. SAKURA Internet がセットアップしたマネージドサーバのアクセス情報を受け取る。
  8. company.co.jp を独自ドメインとして SAKURA Internet のマネージドサーバに設定し、メールアカウントやメーリングリストを先に登録したり設定しておく。（設定すると、SAKURA から割り当てられている company.sakura.ne.jp というホスト名でメールの送受信はできるようになりますが、こんな裏技を社員に教えても混乱するだけなので、放置しました。）
  9. コーポレートの旧ウェブサーバ（IDC でホスティングされていた方）にあるコンテンツを全て SAKURA のマネージドサーバへコピーする。問い合わせフォームはメンテナンスのページに差し替えて、メールか電話での問い合わせに制限する。
  10. company.co.jp のレジストラ移管が完了したので（.org ドメインのレジストラ移管は、ここでの話に影響はないので割愛します。なお、co.jp のレジストラ移管は費用がかかりません）、NS をムームードメインのムームー DNS に変更して、ゾーン・ファイルの内容をムームー DNS の「カスタム設定」へ移植。
  11. MX レコードの変更は業務に大きな影響があるため、日曜日に出勤して、MX レコードや A レコードの設定内容を SAKURA Internet のマネージドサーバへ変更する。ついでに、SPF の設定内容を見直したり、IPv6 の AAAA レコードも追加。
  12. 「DNS の浸透」とか言うな。

以上の作業で、少なくともコーポレートサイトとメールについてはサーバの移設が完了したことになります。

冒頭に戻る

情報セキュリティ事象

日曜日にレコード情報を変更して、もちろんウェブサイトの表示確認やメールの送受信は確認してから会社を後にしました。しかし月曜日に出社すると、幾つかのおかしな現象が起きていたのです。

これらは、それぞれの処理が完了するまでの所要時間であって、個々のプロセスのどこで遅延しているのかが分かりません。これだと対策を講じようがないため、Wireshark でパケットを取得することにしました。このとき、もちろん https や ssh や ftp などのやりとり全てについて通信データを取得してからフィルターで必要なパケットだけを選んでもよいのですが、ひとまずメールは受信に問題はなく、送信が遅いのも SMTP 認証などを使っているからだと思えば済むのに対して（送信できないわけではない）、ウェブサイトへのアクセスが遅いのは話になりません。そこで、まずはコーポレートサイトへのアクセスに時間がかかる原因についてだけ、パケットを取得して調査を始めたわけです。

1 19:29:37 1834 443 TCP 1834 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=4 SACK_PERM=1 2 19:29:37 443 1834 TCP 443 → 1834 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2 3 19:29:37 1834 443 TCP 1834 → 443 [ACK] Seq=1 Ack=1 Win=261340 Len=0 4 19:29:37 1834 443 TLSv1.2 Client Hello 5 19:29:37 443 1834 TCP 443 → 1834 [ACK] Seq=1 Ack=198 Win=6432 Len=0 6 19:29:37 443 1834 TLSv1.2 Server Hello 7 19:29:37 1834 443 TCP 1834 → 443 [ACK] Seq=198 Ack=1305 Win=260036 Len=0 8 19:29:37 443 1834 TLSv1.2 Certificate [TCP segment of a reassembled PDU] 9 19:29:37 1834 443 TCP 1834 → 443 [ACK] Seq=198 Ack=2609 Win=261340 Len=0 10 19:29:37 443 1834 TLSv1.2 Certificate Status, Server Key Exchange, Server Hello Done 11 19:29:37 1834 443 TCP 1834 → 443 [ACK] Seq=198 Ack=3464 Win=260484 Len=0 12 19:29:37 1834 443 TLSv1.2 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 13 19:29:37 443 1834 TCP 443 → 1834 [ACK] Seq=3464 Ack=324 Win=6432 Len=0 14 19:29:37 443 1834 TLSv1.2 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 15 19:29:37 1834 443 TCP 1834 → 443 [ACK] Seq=324 Ack=3738 Win=260208 Len=0 16 19:29:37 1834 443 TLSv1.2 Application Data 17 19:29:37 443 1834 TCP 443 → 1834 [ACK] Seq=3738 Ack=732 Win=7504 Len=0 18 19:29:47 1834 443 TCP [TCP Keep-Alive] 1834 → 443 [ACK] Seq=731 Ack=3738 Win=260208 Len=1 19 19:29:47 443 1834 TCP [TCP Keep-Alive ACK] 443 → 1834 [ACK] Seq=3738 Ack=732 Win=7504 Len=0 SLE=731 SRE=732 20 19:29:57 1834 443 TCP [TCP Keep-Alive] 1834 → 443 [ACK] Seq=731 Ack=3738 Win=260208 Len=1 21 19:29:57 443 1834 TCP [TCP Keep-Alive ACK] 443 → 1834 [ACK] Seq=3738 Ack=732 Win=7504 Len=0 SLE=731 SRE=732 22 19:30:07 1834 443 TCP [TCP Keep-Alive] 1834 → 443 [ACK] Seq=731 Ack=3738 Win=260208 Len=1 23 19:30:07 443 1834 TCP [TCP Keep-Alive ACK] 443 → 1834 [ACK] Seq=3738 Ack=732 Win=7504 Len=0 SLE=731 SRE=732 24 19:30:17 1834 443 TCP [TCP Keep-Alive] 1834 → 443 [ACK] Seq=731 Ack=3738 Win=260208 Len=1 25 19:30:17 443 1834 TCP [TCP Keep-Alive ACK] 443 → 1834 [ACK] Seq=3738 Ack=732 Win=7504 Len=0 SLE=731 SRE=732

上記は Wireshark で取得したパケットを「エキスパートパケット解析（テキストファイルとして）」で表示内容だけ出力したテキストデータを再編集したものです。ちなみに、「エキスパート」は「エクスポート」の訳し間違いだと思います（笑）。再編集したのは、(1) 時刻の小数点以下を削除、(2) 末尾のデータ長を削除、(3) その他、整形あるいは情報秘匿のためにスペースや IP アドレスを削除しています。

TCP/IP を学んで SSL などの暗号化通信をご存知の方であれば、No.1 から始まっている一連の通信が「TLSフルハンドシェイク」の見本みたいなやりとりであることは、すぐにお分かりだと思います。このプロセスには、何の問題もないと思います。が、No.18 のパケットから始まる一連の TCP Keep-Alive のやりとりによって、コーポレートサイトのコンテンツが SAKURA のサーバからレスポンスとして表示され始める No.25 以降のパケットまでは、次のような結果になっています。

  1. DNS を USEN にしたり OpenDNS にしたり Google Public DNS にしても遅い。（接続先を DNS 経由で正式にしても、さくらの初期ドメインにしても、IP アドレスにしても遅い。よって DNS は遅延と関係ない。）
  2. メールの送信に問題がないマシンのアカウント設定を見せてもらったら、なんのことはない、SMTP だけ昔の（まだ落としていない）メールサーバに IP アドレスで接続していたということが分かった。
  3. DNS 関連の作業はひととおり終わって、WordPress サイトの構築もクライアントの確認だけを残している。ということで、DNS を切り替える前から起きていたネットワーク関連の問題を片付けなくてはいけない。実際、自分で使っていても困ることが多々ある。

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

という結果なので、最初は 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] の山が出てきます。ともかく、何か異様な量のやりとりが無駄に発生しているとしか思えないのです。とりあえず、本日の調査はここまでで、あとはネットワーク構築やメンテナンスをお願いしている O 商会さんへログを確認してもらってコメントをもらうことにしました。他にも、6 TB の外付け HDD が認識できなくなって大騒ぎになっているのを、とりあえず USB ケーブルを挿し直しただけで復旧させたり、super full-stack manager は仕事が山ほどあります。

冒頭に戻る

2018年3月23日

本日も朝からネットワークの調査をしていました。すると、なんと目の前にいる人のマシンではメールの送信に全く遅延がなく問題ないとのことです。Windows でも Mac でも Linux (Kali Linux)のマシンでも同じ問題が起きているので、これは個々のマシンの問題ではないはずです。では、どうして一部のマシンだけ問題がないのでしょうか。そのマシンだけ特別なハブを使っているわけでもないし、そのマシンだけが Active Directory 配下だとか SkySea のクライアントが動いているといったわけでもありません。ちなみに、当該マシンの MTU を調べたら、なんと 970 なんて値で、ディフォールトの 1500 だとパケットを断片化できていないようです。僕のマシンで MTU を 970 に変更してもコーポレートサイトへのアクセスは遅いままですが、こういうことを色々とやっているあいだに、最初からアクセスできている Googl Plus 等、一部のサイトの表示スピードがどんどん上がってきています。これは、何の副作用なのかは分かりませんが、良いことなのでしょうか。そして、メールの送信遅延が起きていないマシンについては、次に Wireshark でパケットを取得してみました。また、そのマシンは Active Directory にぶらさがっているので、僕のマシンの NS 設定を AD サーバの DNS に向けてみたり、IPv6 がおかしいという意見もあるようなので無効にしてみましたが、こういうことをあれこれやっても、やはり改善はしていません。同じ社内でも問題のないマシンがあったというのは、これはちょっと更に難しくなってきたような気もします。

次に、レジストリで TCPACKFrequency が設定されていたので、キーを削除しましたが、これも効果がありませんでした。

netsh interface tcp set global autotuninglevel=highlyrestricted

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

他にやったことと言えば、たとえば DNS サーバを USEN（61.122.***.*** / 61.122.***.***）に向けてみたのですが、めっちゃ遅くなりました。それまでアクセスが速かった Google Plus やさくらの会員向けコンパネすらアクセスが遅いと感じます。そこで、ルータと Fortigate とマシンの DNS サーバを Google Public DNS（8.8.8.8 / 8.8.4.4）にしたら、Google にすらアクセスできなくなりました（笑）。これはどうしようもないので、設定を元に戻して、ついでに hp の L3 スイッチではセキュリティ設定を有効にして、DoS などに対応。そして、色々と DNS をいじるとネットワークドライブの接続が切れてしまうため、レジストリの autoconnection の値を間違ったのかもしれません。

さくらでは、company.co.jp と www.company.co.jp で二つの Let’s Encrypt を設定しなくてはなりません。SSL connection 確立の方が www なしから www ありの rewrite よりも優先されるからです。ということで、両方の SNI に対して SSL 証明書を設定したのですが、やはりアクセスは遅いままです。（さくら内での www なし -> www ありの rewrite は速い）そして、

https://www.company.co.jp/test.html

これは遅いので、.htaccess から全ての項目を削除するとアクセスが改善されました。しかし、HTML を PHP で動かせないとインクルードできないので、正常に表示されないページが発生してしまいます。

冒頭に戻る

2018年3月下旬

> netsh interface tcp set global autotuninglevel=restricted > netsh int tcp set global rss=disabled > netsh int tcp set global netdma=disabled > netsh int tcp set global chimney=disabled

これらを実施しましたが、何も変化なしです。O 商会のサポート（UTM 担当）から連絡をもらい、リモートデスクトップで画面を一緒に見てもらいながら確認。UTM（Fortigate）のスキャン機能を全て無効にした通信環境を作って試してみても、やっぱりサイトは遅いままでした。ということで、あとは、

という可能性が残るわけですが、あらためて O 商会の技術者を派遣してもらうことにしました。

冒頭に戻る

2018年4月3日 12:48～

O 商会のエンジニアさんに、

などを見てもらいました。その場でターミナルアクセスもしてもらいましたし、O 商会社内の技術者に改めてリモートデスクトップで色々と確認してもらったり、あるいは当社と同じ UCOM のプロバイダからサイトへアクセスしてもらったのですが、やはりよくわからないとのこと。残るは、

といった可能性はあるので、金曜の夜にルータと Fortigate と L3 スイッチをリブートすることにしました。その他、

RTX3000 # clear dns cache

これも効果なし。当社のサイトの問題だけならともかく、https://tools.ietf.org も遅いのが困ります。それから hp スイッチ（V1810-48, HPE OfficeConnect 1810）も再起動しました。

冒頭に戻る

2018年4月6日 21:00

さくらインターネットでは、サーバのログに特段の異常はないとのこと。

Fortigate DNS キャッシュを削除しましたが、これも特に効果はありません。

> diag test application dnsproxy 7 >diag test application dnsproxy 1

また、ルータ、UTM、L3 スイッチの再起動、Active Directory サーバの再起動も効果なしです。

冒頭に戻る

2018年6月1日

XSERVER に WinSCP でアクセスしたら、全く問題なくアクセスできました。アクセス先によってこれほど違いがあるのは、なぜでしょうか。

冒頭に戻る

2018年6月13日～7月20日

Q 社に相談してみたところ、逆引きが正常にできていないのではないかという話です。調べてみると、USEN の権威サーバに逆引き先として登録してあるサーバの一つが Q 社のメンテナンスしていた DNS サーバで、セカンダリ NS は xname.org という、10年くらい前に派遣で来ていた人が設定した無料の DNS サーバでした。既に Q 社にメンテナンスしてもらっていたプライマリ NS は存在しませんし、xname.org を使い続けるのもどうかと思うので、USEN さんに権威サーバの権限を委譲してもらうことにしました。もちろん、当社で DNS サーバを新しく建てなくてはなりません。

実際にやったことは非常に簡単です。ns.company.co.jp といったドメインの NSD を専用サーバに建てて、逆引きのレコードを設定し、USEN さんから権威サーバの権限を委譲してもらうだけです。権限の委譲は7月20日に完了し、メールの送信や、非常に遅かったサイトのアクセスも改善されました。

冒頭に戻る

最後に

あっけない話で、お恥ずかしい限りです。ウェブサーバの運用だけやってた経験からすると、逆引きなんて有効にすればサーバが落ちてしまう（実際、サーバを落としたことがある）ので、ウェブサーバで逆引きを設定しているところがあるとまでは想像しませんでした。考えてもみれば、日立さんのサイトなど大手のコーポレートサイトが遅かったため、そういう潤沢な予算がある企業のサーバでは、逆引きを有効にしておいた方がメリットは大きいのでしょう。たとえば、IP アドレスだけではアクセス元を正確に区切るのが難しいため、逆引きして gTLD をはっきりさせたら、例えば hinet.net（台湾の ISP で、スパムや不正アクセスが多い）のような文字列だけで判定してアクセスを遮断できます。

冒頭に戻る

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

Twitter Facebook