Webフィルターサーバ実装

ある環境において、ある一定期間YouTubeを見せたくない時間帯があります。例えば不特定多数が操作できるような環境にTVを設置していて、いつでも動画コンテンツを見られてしまうような場合。

営業時間内は、見えるけど営業時間外スタッフがみて、通信コストが跳ね上がるみたいなのを抑制したいなどの用途を想定しています。

どうやって実現？

それをどのように実現するか？って話なのですが、我が家にルータにはURLフィルターて奴が機能としれ備わってます。当初それを使って実装をしていこうと思ったのですが、なんとこの機能は、制限事項として、http通信のみしか制限出来ない。今時のサイトは全て暗号可されており、https通信になっているので、この場合、これらのサイトは制限できない話になってしまいます。めんどくさいですねｗ

では、これらをどうやって制御するか？

色々考えたのですが、内部で対応するのが一番スループットからして良いという結論に達しました。では、考えた方法は、どういう制御をいれるのか？

１．指定時間帯はWLANをタイマー機能でＯＦＦにする
２．指定時間帯該当のドメインに対して無意味な（127.0.0.1）みたいな物を返すＤＮＳサーバを立てる

この２つです。基本的に全者は、YouTube以外も犠牲になるためNGにしました。後者は、美味くやれば可能という結論に至りました。後者をVMサーバとして構築していきます。

仕組み

基本的にLinuxで組みます。内部にBINDかアンバウンドを入れてcacheサーバとして動作させます。BINDの場合、CRONでHOSTSを切り替えて、簡易制御するか、BINDのローカルロケーションを書いてCRONで制御するかにします。

BINDもアンバウンドも定義ファイルを更新すると、再起動が必要なので簡単にHOSTS運用をしようかなと思っています。

Linuxのデフォの名前解決は、HOSTSなので、そちらにまず、下記を設定します。

127.0.0.1   www.youtube.com
127.0.0.1   youtube.com

これを１ファイルにしてCRONで時間で差し替えます。曜日・時間・等で細かく制御できるので非常に便利ですね。haproxyいれて、VMとラズパイで冗長化してVIPを参照にするでもいいかも知れません。

この方式なら、アマゾンプライムやその他の映像配信サービスもドメインが設定されているどんなサイトでも制御可能で有り、https / httpに関わらず制御する事が出来る、最善の方法だと思われます。

ちょっとした案

また、上記設定例では、ローカルホストを登録してますが、立てるサーバのIPを入れてしまえば、例えば、時間外に接続したらapacheが時間外の為見れませんのｈｔｍｌを返却し、見ようとしている人に警告する的なsorryサーバ的な組込も可能かと思います。その場合、httpsで証明書のエラーがでるのできれいには行かないでしょうけどね。
アプリで見ている様な場合も特に、エラー表示しか出ないしょうし。

なお、外部サイトでサービスとしてやっているサイトもあるので、そちらはDNSをそこを見せるだけで、後はWebの設定画面から制御できるんですが、DNSの参照が遅いとか色々書いているので、制御したのいのは、１つか２つくらいなので、ローカルサーバでさっくりやって終わりにしたいと思います。

The post 指定時間YouTubeを見せたくない！！ first appeared on ～下町物語～.

ブログサーバreplace

当ブログサーバですが、諸事情によりreplaceしました。その理由は、これから下に書いて行きますね。

replaceした理由

このブログサーバですが、数点不可解な点があって、何が悪いのか？どうなっているのか？ずーーーーと調査していた案件があります。見た目は普通に何もないですが、ある特定の条件下の元発症するのです。

発症する構成図

どこにでもあるNAT環境です。グローバルIPと言われるいわゆる外部からアクセス出来るIPアドレスは、1つでルーター配下は、全てプライベートIPを振って、ポート番号でアクセス元とアクセス先を紐付けて通信させます。

出典：http://www.geekpage.jp/technology/nat/whatis-nat.php

この時、PC1・Android1・iPhone1・Android2・iPhone2と5台例えば、このブログサイトに接続してみます。

○PC1　通信出来る　×Android1／Android2　×iPhone1／iPhone2　通信出来ない。

不可解な現象

何かの拍子にiPhone1を再起動して、ブログサーバに接続すると、おぉ！なんか接続出来る様になった。もしくはは、Routerを再起動させて一発目はAndroid1で接続すると接続出来る。iPhone1は接続出来ない。Android2は接続出来ない。PCはいつも何も無く接続出来る。一度接続出来なくなると、もうずーっと出来ない。そして、ソフトバンクとか、ドコモとか、AUとかの3G・4G回線から来ると、問題なく接続出来る事。厳密に言うと回線業者によってちょっとまた色々あるので下に書きます。なぞやぁ！これ本当にハゲそうです。

そして分かったんです。

上の構成図で、NATの原理をちょっと書くと、ローカルIPに192.168.1.10(PC) / 192.168.1.11(Android1)/192.168.1.12(Android2)/192.168.1.13(iPhone1)/192.168.1.14(iPhone2)と仮定して、外に出るグローバルIPは、111.111.111.111とします。

PCからこのブログサイトに接続します。192.168.1.10 ->  111.111.111.111にRouterで変換される、その上でDNSサーバに当ブログのドメインを聞きに行く。このブログサーバは、Address: 133.18.171.141がこれなので、このグローバルIPに対して接続を行う。

ブログサーバは、アクセスしてきた端末に対して、ｈｔｍｌをコンテンツを111.111.111.111に送信する。その上でRouterが111.111.111.111に戻ってきた通信を、ＮＡＴテーブルを元に192.168.1.10に送り届ける。

これが、概ねの動作概要になるのですが、複数端末が同じブログサイトにアクセスにきた場合、どうでしょうか？下記の様な構図ができあがりますね。

ＰＣ1———————–>  Ruter 111.111.111.111 -> Blog Server

Android1 ——————>

Android2 ——————>

iPhone1 ——————->

iPhone2 ——————->

Blogサーバからしてみると、同じIPに何度も同じパケットを送っていると思い出す訳であって、そこでふと考える訳です。あれ？もうさっき送ってきたパケットより古い物はもうパケット送んなくていいや！って思い出してパケットは破棄する訳です。

もうお分かりですか？

Linuxには、tcp_tw_recycleという仕組みが用意されています。

そのそも、それってなによ？って話なのですが、TIME_WAIT状態のソケットを高速に再利用するためのLinuxカーネル特 有の仕組という事らしいです。

こいつを有効にした時、同じグローバルIPからの同時に接続した時、TCPパケットにタイムスタンプ情報が入っている場合（Android・iPhone共に付加して送っているそうです）、同 時にパケットを送ると、古いタイムスタンプの方のパケットが破棄されます。

不可解だった、一度接続出来なくなると、もうずーっと出来ないのは、いつまでたっても端末は同じ速度で時間が過ぎて行きます。Android1にしてもiPhone1にしても、同じ1秒は1秒なので、それが逆転する事はありません。よって、接続出来る場合は、ずーっと接続出来るし、接続出来ない端末はもう接続出来ないんです。

パラメーター変更したら良いじゃん

じゃあ！このパラメーターを変更すれば良いじゃん！そうなんです。とっととやってしまいましょう。
CentOS7だと下記のコマンドを打つと出来るんですよ。できるんでよねぇ・・・。

root権限がないと出来ないって！？いや、このユーザrootだしな・・・。そして、悟ったんです。このスーパーバイザー的なアカウントじゃないとパラメーターいじれないんじゃ！？

そうなんです。このブログサーバVPSを借りて居るので、VPSのホストサーバの設定に引きずられるんですよ。この仮想化ソリューションでは、もう絶対にいじれない神の領域なんです。という事で、replaceする事にしました。思い立った時が、replaceのタイミングなんで、とっととやってしまいましょう。

replaceを開始

ちょうど、ひな形のスナップショットを作成するチャンスだったので、監視エージェントとかjenkinsスレーブとか全部入れてひな形化して、スナップショットとった後でブログサーバに設定する事にしました。

WordPressのデータをtarで圧縮してローカルPCにダウンロード。mariaDBの設定全部まるっと、dumpとってローカルPCにダウンロードして、該当サーバへ移設する。必要なPackageを入れてWebサーバに仕立てる。dumpを戻したり、zabbixの個別設定をしたりして、昨日2時間くらいで別のサーバで稼働させてDNSを書き換える。間もなく24時間くらいが経過して、やっとアクセスは新サーバの方に移りつつある。完全に通信が止まったらインスタンス削除して完了。

番外編

通信回線の業者に寄って、グローバルIPを付与しない業者も時折あります。なので、NAT環境のでかい版と考えてもらうと、そこの通信業者で私のブログを見てくれている方がいらっしゃいましたら、同様に起動時間の古い方は繋がらないという事が想定されます。また、ドコモもグローバルIPはふるものの、複数端末にグローバルIPを振る方式を採用している為、同様の事象になる可能性があります。
よって、1つでも、2つでもアクセスしようとされた方が接続出来ない状況を避ける為、replaceと相成りました。

1つ、エラーログに大量にログを書かれているのは認識していたのですが、それも先ほど1つのPackageがインストールされていない事により発生している事と、php.iniを移行するのすっかり忘れてて、php.iniがありませんでした・・・org それでも、普通に動くんですねｗ全部デフォルトって事だったんでしょう。日本語の処理が上手く出来ないってエラーだったので、すぐ気がついたので良かったですけどね。

The post こんなに速くreplaceするとは思わなかった first appeared on ～下町物語～.

原因は誤った経路制御、海外事業者のオペレーションミスか？

本日昼頃発生した日本全土をほぼ覆う程の通信障害について、原因を特定した模様である。

こちらのブログの監視ツールでも検知されていた！

今回の通信障害の原因は、インターネットの通信パケットを正しい宛先（IPアドレス）へ転送するためにネットワーク事業者間で共有している経路制御（BGP：Border Gateway Protocol）の情報に、誤った経路の情報を流してしまったネットワーク事業者がいたことによるものとみられる。これが意図的なのか、オペチョンによる物かは判明はしていないが、これからどこの業者がその情報を流してしまったのか？順次調べを進められる事になるだろう。

BGPについて急上昇ワードがえらい事に！

でも、これをみてどれだけの人が理解しただろうか？我々インフラをやっている人間からすると、まあまあ普通の事なのだが、一般人がみてもこれは絶対理解出来ない代物だと思う。ルーティング？プロトコル？なんぞやそれってならないですかね？下記が分かり安いかなと思うけど、結局ルーターやらスイッチが何をどうしているのかを理解出来ないと、読み解けないと思われる。

主原因は、下記じゃないかと言われてる

OCNが相互接続している海外の大手ネットワーク事業者が、OCNのネットワークへ転送すべきIPアドレスに対し、本来は経由すべきではない自社のネットワークへ転送するよう指定してしまった模様だ。そこのパケットの流れを制御しているBGPがOCNのパケットを根こそぎでデータの流れを自社の広域網に流れを変えたことにより、これらの傷害が発生したとのこと。おそらく、そこの通信もOCNからのパケットが大量に押し寄せてパンク状態になり、パケットが衝突しまくり、経路が違う事により正常にパケットが流れなくなり、最後はTCP/IPの理屈でポイされて、パケットが潰れていく感じかなと想像している。

影響を受けたIPアドレスについて

今回の経路障害の影響が及んだIPアドレスは、世界で約10万アドレス。このうち日本国内が約2万5000アドレスだという。ここのブログもなんと、504Gateway Timeoutを返して一時繋がらなくなりました。影響を受けたIPアドレスになりました。なんてこった！どうしようもねーやなぁ。ＳＡＫＵＲＡもＡＷＳもSlack影響を受けていたとの事なので、軒並み全部駄目だったんでしょう。Slackが繋がらなくなった為、全く仕事が出来なくなったのも事実でｗ

今後の対策は？

ってこんな事書いても、対策は無しって感じですかね。オペチョンについては、誰でも起こすこともあるし、それをシステム化しても、結局バグってると、結局発生してしまう。という事は、絶対って事は無いので、1％でもその確率を少なくする事が必須かと思われる。

The post OCN大規模通信障害発生 slack/AWS繋がらず！原因報 majikayo! first appeared on ～下町物語～.