Chrome で証明書エラーが出るようになった

ボクは自宅サーバを立てているわけだけれど、SSL 証明書オレオレ証明書を使っている。が、オレオレ証明書は当然ボクが勝手に発行した証明書なので、インターネットの世界では信頼性がない。証明書は本来「認証局」と呼ばれるインターネット上で信頼性が担保された機関によって発行されたものでなければならないのだ。
とはいえ、それにはお金がかかるし(最近では無料のものもある)、そもそも暗号化さえできれば良いので、オレオレ証明書を使っている。で、ウチのサーバを「信頼していい認証局ですよ」と PC に登録することによって、エラーが出ないようにしているのだ。

ところが、数日前から Google Chrome でボクのサイトを開くと証明書エラーが出るようになった。よくよく調べて見ると、証明書には当然そのサイトのドメイン名(うちなら amatsukam.jp)が入っているわけだけど、それの参照する場所が変わったらしい。ボクが発行した証明書には Google Chrome が参照する値が入っていないのが原因だった。

Google Chrome が参照するようになったのは「X509v3 Subject Alternative Name(略称:SAN)」というものらしいのだが、これは証明書で設定するのではなく、認証局側で設定するらしい。というわけで、amatsukami.jp の SSL 証明書をウチのサーバの認証局で発行する際に、この SAN を設定することによって解決できた。

下の写真は会社に行く途中の歩道橋に乗り捨ててあった自転車。帰りに撮ったんだけど、行きは倒れた状態で歩道の階段をほぼ塞いでいた。あれかなー、酔っ払って盗んで乗って帰ってきてこの辺で捨てたって事なのかな? もし盗まれたものだとしたら、持ち主がここにあることを知ることはなかなか難しい気がした。
ちなみにその後、この自転車は歩道橋を上がった歩道にずーっと少なくとも 7  月 31 日までは置かれていた。その後は渋谷の出向が解かれたので、解らない(汗)。

LAN には LAN のお名前を…

先月の話になるが、自宅 LANDNS を少し見直した。
amatsukami.jp のいくつかのサービスで、LAN 内でしか利用できないようにしてあるものがあるのだが、それを外部から利用することは当然出来ない。WAN からのアクセスはハネているからだ。LAN 内のマシンは hosts ファイルにて自宅 LAN 内のサーバをすべて登録してあり、ローカル IP にアクセスすることによってサービスが使えるようになっている。
しかしこの hosts ファイルは普段持ち歩くタブレットやノート PC などには設定できない。LAN の外で使うこともあるからだ。外にいる場合、amatsukami.jp に関わる IP アドレスはグローバル IP でアクセスしなければならない。LAN 内だけで利用できるサービスをどうしても使いたい場合は、VPN をつなげれば使うことが出来るものの、LAN 内のサーバを定義した hosts ファイルがないためグローバル IP でアクセスしてしまい、結局 LAN 内だけのサービスは利用できなかった。

そこで、VPN を繋いだときだけ、サーバの IP はローカル IP を返すようにしたのだ(今頃)。

仕組みは簡単で、LAN 内用の DNS サーバに hosts ファイルと同じ設定をしただけである。またこうすることによって、LAN 内のマシンも hosts ファイルを必要としなくなった。
最初からこうしておけばよかった……(^^;

さて、下の写真はお昼に食べた『なごみ』のつくね定食と、夜、知人の家族に誘われて行った『高倉町珈琲』の小平店の写真である。そう、高倉町珈琲は今まで武蔵村山店がウチから一番近かったのだが、より近い小平に出来たのだ。

つくね定食はタレをご飯とまぜながら食べられて、しかも半熟卵(温泉卵?)も適度にご飯の上でつぶしてやると、濃厚な卵かけご飯になって、いろんな味が楽しめてオトクだ。
つくねは軟骨がないタイプだが、みっしりしていて歯ごたえも充分。
美味しかった。
1602028154 1602028156

高倉町珈琲の方は、前回、前々回とやはりホットケーキが飽きるのではないかと思っていたのだが、ホットケーキが少し変わっていた。まず中身がけっこうスカスカ。元からスカスカではあったが、一層スカスカになった気がする。そのため軽くて、フワッとしていて、食べやすい。さらにホットケーキの重なっている間にメレンゲが敷いてある。これがまた余計にふわふわ感と軽さをホットケーキに与えていて、クリームたっぷりでもしつこく感じる事なく、また飽きることなく食べることが出来た。
オムライスも独特で、これも表面の卵の下は白身ベースなのね。フワッとしていて、ご飯との緩衝材になっていて、こちらも軽い感じで食べられる。いろいろ工夫してるんだねぇ。
1602028159 1602028161 1602028165

オープン リゾルバ事件

勤め先の会社は三つの開発室があるんだけど、それらのネットワークを管理している。で、そのうちの一つの開発室で利用しているプロバイダから、どうも大量の不正パケットが流れた形跡があると連絡をよこしてきた。
ログをみたら、一目超然、DNS amp 攻撃だった。

ぎゃーす! そういえば、DNS の設定ってどうなってたんだっけ?<ヲイ
って色々調べたら、amatsukami.jp サーバもオープン リゾルバになっていた……orz

皆さんがウェブサイトを閲覧するとき、そのサイトを運営しているサーバに正しくアクセスするためには DNS という仕組みが不可欠である。インターネット上のサーバはすべて一意の重複することのない番号(IP アドレス)が割り振られていて、この IP アドレスはグローバル IP アドレスと言って、インターネット内で重複しないように割り振られている。例えば今あなたが見ている TAMA Networks を提供しているサーバのグローバル IP アドレスは 210.136.205.247 であり、これは世界に一つしかない IP アドレスである。この番号を他の誰かが使うことはない。
でもこの 210.136.205.247 という数字を使ってデータをやりとるするのは非常に非効率だ。この数字は将来的に変わるかもしれないし、この IP アドレスで提供されるサービスは一つに限ったことではない(FTP、メールなど)。
そこで、この数字と抽象的な名前(○○.co.jp とかのことで、これをドメイン名という)を関連づけることによって、柔軟なアクセスを提供するのが DNS という仕組みだ。たとえば、TAMA Networks のブックマークをブラウザで呼び出すと、ブラウザは amatsukami.jp にアクセスしようとする。ブラウザはまず DNS を提供しているサーバに「amatsukami.jp は何番でっしゃろ?」と問い合わせに行くのだ。すると、DNS サーバが「210.136.205.247 でんがな」と答えてくるので、ブラウザはその DNS から答えられた番号の振られているコンピュータ(サーバ)にアクセスしに行くのである。
これはなにも amatsukami.jp に限ったことではなく、世の様々なサーバ(sony.co.jp とか honda.co.jp とか)すべてがこの方法でアクセスしたいサーバを求めており、これを名前解決と言い、このような DNS サーバを「フルサービス・リゾルバ」という。

ではどのフルサービス リゾルバ DNS にアクセスしに行くのかというと、それは各プロバイダが提供している。他にも Google なんかが自由に使える DNS サーバを用意してくれたりしているし、自分で設定することも出来る。
また会社では会社で建てたフルサービス リゾルバ DNS サーバがその役を担い、ウチの会社もそうなっている。

さて、では DNS サーバというのは全世界中の IP アドレスと名前の情報を持っているのかというと、そう言うワケではない。DNS サーバは例えば「amatsukami.jp は何番よ?」と問い合わされたら過去に同じ問い合わせがないかをまず調べる(キャッシュ)。なければ、.jp を管理している DNS サーバに問い合わせに行く。すると .jp を管理している DNS サーバは「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」と返してくるので、210.136.205.247 に問い合わせに行くと、210.136.205.247  の DNS サーバ(つまりボクのサーバ)が amatsukami.jp に関する様々な名前と数字の対応を返すのである。このようにフルサービス リゾルバは、次々とより上の DNS サーバに問い合わせていくようになっていて、これを再帰呼び出しと言う。
amatsukami.jp に関する様々な名前というのは、例えば ftp.amatsukami.jp や www.amatsukami.jp など、amatsukami.jp がつく様々な名前である。ここで初めて、amatsukami.jp も 210.136.205.247 だとって返ってくるので、これを問い合わせしに来た機械に渡すのである。
この時、この「問い合わせをしに来た機械を詐称」することができる。
つまり本来は、A というコンピュータが「amatsukami.jp は何番よ?」って聞いてきたら、その結果を A に返すはずなのだが、ここを B というコンピュータに返せとすることが出来てしまうのである。
こうすることによって DNS サーバは B に答えを送ってしまうどころか、本来定義されていない情報を問い合わせる(この問い合わせ内容が、普通の DNS 問い合わせより遙かに情報量が多いように細工されている)ことによって、DNS サーバはコンピュータ B の回線をパンクさせてしまうのだ(実際には何万台という乗っ取られたパソコンをつかって、DNS サーバにこのような攻撃を行う)。
そのためフルサービス リゾルバは、インターネットの誰からでも受けてはいけないように設定しなければならない。そもそもこの名前解決の問い合わせは各プロバイダが提供しているのであって、わざわざ他人のサーバに問い合わせる必要などない。従ってウチも社内でのみ、このサービスは提供すべきなのである。

ではなぜそれがインターネット全体にも提供していたのか?
それは上の説明にも出てきた「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」という部分である。ボクのサーバは全インターネットに向けて、amatsukami.jp に関してのみ責任を持って名前解決をしなければならない(こういう DNS サーバをコンテンツ サーバという)。
amatsukami.jp のついたものに関しては、ボクのサーバだけが真実を知っているのである(実際には真実を知っているサーバを定義することが出来るが)。
そして Microsoft の DNS サーバは、フルサービス リゾルバとコンテンツ サーバを分離出来ない。もし分離したかったら、フルサービス リゾルバ用の DNS と、コンテンツ サーバ用の DNS をそれぞれ別に立てないといけないんですな(ちなみに UNIX の世界で使われている BIND という DNS のプログラムは、この二つの機能を分離出来る)。

まぁ、Windows でも BIND 使うべきなのかもしれないけどね……。

で、とりあえず会社の方はコンテンツ サーバとしての役割を他の外向けサーバに移し、ルータ側で DNS の外部ポートを閉じた。
一方の amatsukami.jp は LAN 内の Active Directory を提供しているマシンにフルサービス リゾルバを設定し、SMTP(メール)のゲートウェイをしているサーバに新たに DNS をインストールし、そちらでコンテンツ サーバとして設定した。これで amatsukami.jp サーバがオープン リゾルバではなくなった。

あー、説明が長かった……orz
ちゃんと正しく説明できているかなぁ……。

コリジョン?

社内 LAN が時々おかしなことになることがあったのは前から認識していた。納期前の修羅場ということもあり、とりあえずルータをリセットすると  24 時間くらいは大丈夫なので、だましだましつかっていた。が、ボクらのつかっている建物に、どんどん本社から人が移動してきて、20 人を越えるようになってきた。さすがにその状態で LAN がおかしいというのは問題だろうということで、本格的に調査することにした。

まず症状はとにかくひたすらネットが重くなると言うことだ。普通にネットサーフィンもままならない。LAN 内のマシンに Ping を飛ばしても 1000msec 以上反応が返ってこないことがザラな状態である。また、ルータをリセットすると直ることから、ボクは最初、ルータを疑った。とはいえ買ったばっかり(8 ヶ月くらい)なんだよなぁと思いつつ、ルータのインジケータを見てみると、けたたましく LED が明滅している。
うへ、これループじゃネーの? というわけで、みんなが帰って一人で残っているときに、まずルータから HUB につながっている LAN ケーブルをすべて抜いた。ところが LED は相変わらずけたたましい。おやぁ? あと刺さっているのは、無線 LAN アクセス・ポイントとサーバだけなんだけど。というわけで、無線 LAN アクセス・ポイントの LAN ケーブルを抜く。
しかし症状変わらず。

ええっ!? サーバなの!? なんでっ!!??

サーバは二枚の NIC がありそれぞれ別の IP アドレスが割り当てられている。とりあえず、主サービスを提供している側(もう片方は SMB しか提供していない)の LAN ケーブルを抜いてみると見事に LAN が正常に動作するようになった。うへぇ、サーバがいったいどんな悪さを!?

それからというもの、サーバで提供しているサービスを一つ一つチェックするという地道な作業が……。もう一つ恐怖心もあった。これが朝まで直らなかったら、20 名以上の社員が仕事にならなくなる。そんなことになったら、会社全体に大きな損失を与えることになってしまう。うひー!!
で、ふと思ったのが、主に起きるトラブルが、まぁ LAN そのものが重いってのもあるんだけど、名前が引けなくなるってことなんだよね。名前が引けない──名前解決が出来ない──っていうのはどういうことかというと、インターネットというのは IP アドレスという数字で自分や相手を特定するんだけど、数字だけではとてもじゃないがわかりにくいし、数字が変わったときに対応しづらい。そこで名前を数字にしてくれるサービスというのがある。
たとえば、amatsukami.jp というのは「61.115.113.146」という数字が割り当てられているんだけど、みんなボクのサーバにアクセスするのに「61.115.113.146」なんて数字は入力していない。「amatsukami.jp」という名前でアクセスしている。つまり「amatsukami.jp」に行きたいんだけどっていうのをとある場所に投げると、それは「61.115.113.146」ですよって答えを返してくれるサーバがあるのだ。それを DNS サーバっていって、だいたいプロバイダによって提供されている。
うちの会社の場合、この社内サーバが DNS を提供している。

ところが、だ。この DNS サービスを 2 枚の NIC 、両方でサービスしていた。この NIC にはそれぞれ異なる IP アドレスが割り振られている。仮に IP:192.168.100.1 と IP:192.168.100.2 としよう。

どういうことが起きるか? じつはボク自身、よく解ってない(マテ)。
たとえば「amatsukami.jp」って何番? っていう問い合わせに対し、192.168.100.1 と 192.168.100.2 両方から「61.115.113.146」だよって答えを返してしまう。LAN 内にまったく同じデータが、異なる IP アドレスから発信される。それが何か悪さをしているとか? でもそもそもクライアントは 192.168.100.1 にしか問い合わせに行かないはずだ。ということは名前解決ではなくて、DNS 広報(DNS の情報を他の DNS サーバに伝える)の方で同じようなことが起こっているのだろうか?
いずれにせよ、この二つの IP アドレスでサービスしている DNS サービスを、メインのアドレスのみにしたら直った。
ひー、朝までに直って良かった~~~。ちなみにその時のツイート