wifi, ネットワーク, 運用管理

あらまし

x月x日、某社オフィスで
「社内無線LANが使い物にならず非常に困っている」
という相談を受けました。

特に繋がらない場所は会議室であり、iPadでFaceTimeを使ったテレビ会議をしようとすると、映像がブラックアウトしたり音声がブチブチ切れるという悲惨な状況だというのです。さらに会議室以外でも通常なら数分終了する構成管理ツールが、なんと70分も掛かるなどの事例が報告され、社員は無線LANに対して大きな不満を抱えているとのこと。つまり……

今すぐ解決してほしい!

ということです。今すぐに解決できるわかりませんが、まず調査してみて、対処できることからトライしてみようと思います。

無線LANが不安定になる原因

  1. 電波が弱い
  2. 混雑している

オフィス無線LANが不安定になる原因の多くは混雑です。同時に多数の端末が通信できているように見えますが、有限のチャネルを時間で分割して利用しています。

ひとつのチャネルを5台の端末で共有
ひとつのチャネルを5台の端末で共有

無線LANの特徴として、端末ごとに通信状況が異なることがあげられます。これは、伝送媒体の品質が保障できる有線と違い、電波の状況が悪くなっても接続を維持できるように、端末ごとにデータレート(bps)をつねに変化させています。電波状況は刻一刻と変化していますので、それに追随してデータレートも常に自動調整されています。

OS X では Option + 無線LANアイコンクリックで 現在のデータレートなどを確認できます。電波の状況があまり良好でないときは、クリックするたびに数字が変化しているのを見ることができるでしょう。

そのうち一台(オレンジ色)の端末が遠くに行ってしまい、電波状況が悪化したため、データレートが 2Mbps まで低下したとします。すべての端末に 100KB を転送すると

全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)
全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)

なんということでしょう! 遅いデータレートの端末が一台いるだけでかなりの時間を消費し、チャネルを共有している全端末のパフォーマンスが大幅に劣化してしまいました。

この遅いデータレートの存在があると、無線LANに収容できる端末数は大幅に低下します。無線LANでは制御も同一チャネルの半二重で行うため、チャネルの空き時間が少なくなると制御も困難になり、全体が一気に不安定になってしまいます。

この場合、ボトルネックになっているのは伝送媒体である空間そのものですので、同じチャネル×空間にアクセスポイントを増設しても改善されません。

高密度無線LAN環境において遅いデータレートは悪!

オフィスなどの高密度無線LAN環境では、遅いデータレートの端末が発生しないよう考慮します。遅いデータレートでの接続を禁止する設定ができるアクセスポイント製品もあります。

データレート制限機能の例
データレート制限機能の例

データレートが速いほど、より高品質な電波状況が要求されます。遅いデータレートでの接続を禁止してしまうと、電波状況が少しでも悪化すると切れてしまうことになります。端末が移動したり、何らかの原因で電波状況が悪くなったとしたら、より近くのアクセスポイントへローミングを早めに行わせます。

※ローミング 複数のアクセスポイントが同じSSIDで設置されている場合、端末は最も良い電波状況のアクセスポイントを自動的に選んで接続し、電波状況が変化すれば別のアクセスポイントへ接続先を変更する。

続く:: つながらない無線LAN!?(2/3) 調査編


初めまして、申し遅れましたが新人ツチノコのkumaです。よろしくおねがいいたします。

イベント, デザインパターン, 勉強会

今年もJuly Tech Festaで登壇の機会をいただいたのでスキルパターンを作った話をしてきました。

JTF2015(July Tech Festa)
http://2015.techfesta.jp/

眠け覚ましにミニワークショップもやってみたのですが、わりと楽しんでもらえたようです。

他のセッションは格好良い技術ネタが多かったようで、この発表がおそらく最ユルセッションだったんじゃないかと。


ちなみに去年はわりと硬めに、DMMのインフラの裏側についての発表をしています↓

SSL, 運用管理

老若男女の皆様初めまして。

映画大好き下っ端新米ツチノコのshirokumaと申します。

ツチノコなのにshirokumaです。ʕ゚ᴥ゚ʔガオー!!

 

ところで皆さん『ターミネーター:新起動/ジェニシス』は見ましたか?

これから見る方はぜひターミネーター1と2を予め見ることをオススメします!

 

あ、watakenさん!僕が読んでるライトノベルはこちらですよ!

 

さて、本題ですが今回の記事はSSLに関するお話です。

 

shirokumaは主にDMMサービス運用を担当しているのですが、

サービス運用を行う上でSSLの更新は必須の定期業務です。

サービスの運用を行っているエンジニアの方であれば皆さん一度は経験があると思います。

 

そんなSSLについて総務省から以下の様な発表がありました。

http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/enduser/security01/12.html

 

SHA-1からSHA-2への移行についての発表です。

SHA-1からSHA-2への移行にて最も影響を受けるものはフィーチャーフォン(ガラケー)だと思われます。

 

なので、各キャリア様からも以下の様なお知らせが出ております。

NTTdocomo様

https://www.nttdocomo.co.jp/info/notice/pages/150715_00.html

KDDI様

http://www.kddi.com/important-news/20150715/

SoftBank様

http://www.softbank.jp/mobile/info/personal/news/support/20150715a/

 

一部のフィーチャーフォン端末ではSHA-2に対応できていない実情があります。

この辺りは各社の運用を行っているエンジニアが頭を悩ましているかと思います。

shirokumaもその一人です。タスケテ!

 

さらには、先日シマンテック様よりこんな発表がありました。

以前は必須となっていたクロスルート証明書の設定が今後はサーバの用途に合わせて有無を選ぶ事になりそうです。

 

そんな紆余曲折を辿りそうなSSLの中間証明書についてのナレッジご紹介致します。

SSL証明書の更新業務はshirokumaの様にエンジニアとして日が浅い人間が実施する機会が多いかもしれません。

そんな人達の助けになれば幸いです!

 

事の発端はshirokumaがSSL更新作業を行った後の中間証明書の正常性を確認をしている時でした。

弊社では確認手段としてmodern.IEのXP環境にてIE6のブラウザで階層構造を確認していました。

これは以下の二点を踏まえてshirokumaが決めた運用となります。

  • 最近のブラウザでは中間証明書をキャッシュする機能があるので確実な確認手段として不適切である。(初期のIE6にはキャッシュ機能はありません)
  • 実際にユーザーが見るのはブラウザを使うのだからできるだけブラウザで行いたい。

弊社では中間証明書を適用する際はクロスルートを証明書込みのものを利用しているのでXP環境では4階層に見えるはずです。

 

ʕ゚ᴥ゚ʔ  「さて、証明書更新も終わったし今日の晩ご飯何しようかなぁ・・・・・・・・ん?」

shirokuma-001

 

三階層になってるうううううううううううううううううううう!?!?!?!?!?!?!?!?!?

ええ。焦りましたよ。そりゃもう。

設定した箇所や手順を見直しても特に間違っている点はありません。

試しにテストページをフィーチャーフォンで開いて見たところ正常に開けました。

 

ʕ゚ᴥ゚ʔ  「クロスルートが適用されているのに3階層で見える・・・・?」

002

ʕ゚ᴥ。ʔ  「ルート証明書が自己証明しているように見え・・・・る・・・・?」

 

青狸に助けを求める眼鏡少年の如き勢いでシマンテックカスタマーサポートに連絡を取りました。

すると以下の様な事を懇切丁寧に教えてもらえました。

※シマンテックカスタマーサポート様、本当にありがとうございます。

 

Q : そもそもブラウザで見る事ができる『4階層』と『3階層』って何が違うの?

A: 違いは『VeriSign Class 3 Public Primary Certification Authority – G5』(通称:G5証明書)がOS/ブラウザにインポートされているかどうかで変わります。G5証明書はシマンテック(旧:ベリサイン)のルート証明書です。ルートのG5証明書はブラウザの階層チェーンには表示されない仕様なので、G5証明書がブラウザにインポートされていれば3階層』『G5証明書がインポートされていなければ4階層』といった形で表示されます。

 

詳細を以下の表にまとめてみました。

003

 

 

Q : G5証明書がインポートされていない環境って?

A: 最近のブラウザではPC/スマフォ問わずにG5証明書が予めインポートされています。ですがwindowsXPのSP2以前やフィーチャーフォンの一部端末はG5証明書がインポートされておらず、『VeriSign Class 3 Public Primary CA』(通称:G1証明書)がインポートされています。G1証明書は直接G3証明書をチェーンする事ができないので必ずG5証明書が必要となります。

 

Q : G5証明書って二種類あるの?

A: 非常にややこしいのですが、『VeriSign Class 3 Public Primary Certification Authority – G5』は全く同じ名前でルート証明書とクロスルート証明書がそれぞれ存在します。なので、証明書のChainを確認する際は表示されている『VeriSign Class 3 Public Primary Certification Authority – G5』がルート証明書なのかクロスルート証明書なのかを必ず確認してください。

※shirokumaがXP環境で確認した際に自己証明されていると見えたものはG5ルート証明書がG5クロスルート証明書を証明していた結果です。ややこしいですね。

 

—–

SSLは普段業者から発行されたものを手順に従って適用していたので深く調べた事が無かったのですが、シマンテックカスタマーサポートに問い合わせて色々聞いてみると奥が深かったです。
頂いた情報を元に弊社のXP環境で3階層に見えた理由を調べてみると……..

 

ʕ゚ᴥ゚ʔ  「あ、WindowsUpdateでIE6がSP3にバージョンアップしてる」

※IE6のSP3以降は『VeriSign Class 3 Public Primary Certification Authority – G5』がインポートされています。

「環境変わってるじゃねぇか!」と言われました。しょうもない理由で申し訳ありません・・・・・orz

 

—-

今後のSSL証明書更新後の中間証明書確認方法について

カスタマーサポートの方からお話を聞いた結果以下の方法が現在のbestと考えております

■対象SSLがインターネットから参照できる場合

Symantec SSL Toolboxを初めとしたインターネット上の確認ツールを使うのがbestかと思います。ただし使用する際はツールがどういった条件(確認する際に使用するルート証明書等)についてよく確認してから使用してください。ちなみにSymantec SSL Toolboxは『VeriSign Class 3 Public Primary Certification Authority – G5』のルート証明書を前提で確認するとの事です。

■対象SSLがインターネットから参照できない場合

Linux環境にて以下の様なopensslコマンドを実行してChain情報を確認する方法がbestかと思います。

 # openssl s_client -connect example.dmm.com:443 -showcerts

 

一先ずこのポリシーで今後は確認をしたいと考えています。

もっと良い方法をご存知の方が居ましたら教えて頂ければと思います!!

—-

ついでに聞けたこと

『VeriSign Class 3 Public Primary Certification Authority – G5』がインポートされているブラウザにてサーバ証明書が設定されたページにアクセスすると中間証明書が設定されていないor間違って設定されていたとしてもブラウザが自動で中間証明書(G3証明書)をダウンロードしてChainしてくれる機能があるそうです。すごい!

※推奨はされていません。必ず正しい中間証明書を設定しましょう

セキュリティ, ネットワーク, 運用管理

本日 「うるう秒」の挿入が行なわれましたが、みなさま無事だったでしょうか?

参考)  閏秒 – Wikipedia

DMMで行なった「うるう秒」対策は以下の6点です。

  1. うるう秒による影響調査
  2. ネットワーク機器の対策
  3. ゆっくり時刻を合わせるNTPサーバの構築
  4. 大量のサーバのNTPの設定変更
  5. パブリックNTPサーバとの通信遮断
  6. 当日待機

うるう秒による影響調査

ベンダーからのアナウンス情報、3年前の事例、NTPのプロトコル調査、等を行なって以下の問題があることを事前に洗い出して、チーム内周知を行ないました。

  • うるう秒で問題が発生する要因は大きく2つ。
    • NTPプロトコルでうるう秒対策に使われる、リープインジケータ(以下LI)をうまく処理できないLinuxサーバが存在する。
    • うるう秒挿入をうまく処理できないアプリケーションがある。
      • 60秒の挿入、時間の巻き戻り、にうまく対応できないソフトウェアがある。
  • 3年前には、MySQL、Java、で高負荷になる事例があった。
  • LIを受信しなければ、LIに起因する問題発生は回避できる。
    • LIを受けるタイミング(うるう秒挿入の24時間前からうるう秒挿入までの時間)でNTPサーバを停止すれば問題は回避可能。
    • LIを送信しないNTPサーバを使うことでも回避可能。
  • NTPをslewモードで動作させれば、ゆっくり時間を合わせるので時間の巻き戻りをある程度回避できる。
    • ただし、NTPの古いバージョンではうるう秒の時のslewモードにバグがある。
  • ネットワーク機器についての情報は各ベンダが情報を出してくれている。
    • 問題があるものはファームウェアを上げることで対処可能。
    • ファームウェアを上げられない場合は、NTPサービスを停止することで問題回避は可能。

ネットワーク機器の対策

機材によって以下の2つ対策を使いわけました。

  • ファームウェアのアップデート
  • 前日からのNTPサービスの停止

ゆっくり時刻を合わせるNTPサーバの構築

LIを流さずに、ゆっくり時刻を合わせるNTPサーバがあれば、うるう秒による問題は回避できます。

そんな製品がありました。

このアプライアンスサーバを最上位(stratum 1)のNTPサーバとして、複数のNTPサーバを用意しました。

大量のサーバのNTPの設定変更

DMMには大量のサーバがありますが、そのサーバのNTPの設定を確認してみたところ、いろいろなNTPサーバを参照していました。

なんてこったい。

Ansibleを使って、一気にNTPサーバの設定変更を行ない、NTPサーバの再起動を行ないました。

設定の標準化できて一石二鳥。

パブリックNTPサーバへの通信遮断

DMMには本当に沢山の機材があって、上記の対応をしても、更新漏れの機材がある可能性があります。

万が一に備えて、前日から24時間、参照している可能性があるパブリックNTPサーバへの通信を遮断しました。

ルータのルーティングテーブル上で、/32の経路をdropする、という乱暴なことをしています。

当日待機

念のため当日待機もしましたが、残念なことに、幸いなことに、何もありませんでした。

めでたしめでたし。

PAGE TOP