DNSラウンドロビンについて考える

最近DNSラウンドロビンの構成になっているWebサーバを見かけなくなったのは、ロードバランサが仮想化されて稼働率が限りなく100%に近づいているからということなのか?
とあるサービスにて、複数のロードバランサをDNSラウンドロビンする方法があったのだが、ロードバランサに障害発生した場合に、DNSラウンドロビン登録しているAレコードのキャッシュ有効時間を限りなく短くしたうえで、ロードバランサ障害時にDNSレコードを動的に変更できる運用体制がないと可用性を下げる要因にしかならないのではないか?と思ってみた。
DNSラウンドロビンにおいては、
WindowsでDNSのラウンドロビン機能を利用するの文中にあるように
クライアント側の再試行機能(アクセスできない場合は、別のサーバIPアドレスへの接続を試行する)に”期待”したりする(アプリケーションによっては、アクセスできない場合は自動的に別IPアドレスへ再試行する機能を持っている)
とあり、アプリケーションの実装によっては、アクセスできない場合には別のAレコードの値を参照して再試行するというものがあるらしいが、アプリケーションが直接複数のレコードを使い分けるような実装をしているものがあるとは個人的には考えにくい。
参考)
Load Balancing
Azure Load Balancer の概要

無線中継器を設置してみた

最近、周りで高出力?の無線LANのアクセスポイントが増えたせいか、親機のWZR-HP-G301NHの電波が2階まで届きづらくなった。
WEX-733Dを検討していたが、パソコン工房でジャンク品として500円でたたき売りされていたMZK-W300NH2があったので、異なるメーカでブリッジモードで接続できるかどうか試してみた。
結論としてはうまくいかなかった。
どうもアクセスポイントとしてもかなり評判が悪いようで、異なるメーカでの中継設定をしたサイトにはたどり着けなかった。
MZK-WNHのAPブリッジ(WDS)設定

MZK-W300NH2 でAPブリッジ
などあり、あまり評判がよくない。
PLANEX MZK-W300NH2 で WDSに至っては、EDIMAXのBR6424n V2へのファームウエア更新の方法までのっていた。
うまくいかなかったので、ガラクタ覚悟でファームウエア更新もやってみたがうまくいかなかった。
すこし高い授業料だったが、ブリッジモードで接続する場合には、同一メーカで構成することが無難であることがよく分かった。。。

mydnsからroute53へ移行する

dynamic dnsサービスであるmydnsからAWSのroute53へ移行してみた。
dynamic dnsの移行なので、いろいろ考慮しないといけない点はあるものの、オンプレのDNSサーバを移行するのであれば、かなり楽に移行できそうな感覚だった。
理由は、
・mydnsサービスが昨年使用できない障害が2度発生していたこと(無料で利用させて頂いているだけに何も言えないのですが、DNSが引けなくなることでインターネットから孤立するのは辛すぎる)
・AWS移行検証に当たってまずは移行しやすい部分からやってみたかったこと
やってみて分かったこと
・route53のインターフェイスは英語。でもなんとかなる。
・1ドメイン当たりの管理コストは0.5ドル。
・IPv6をダイナミック管理しようとすると、自前で作らないと難しいかも。(後述記載のサービスの安定性に依存してしまう)
AWS route53セットアップ(2ページ目は使用しない)
Route 53でダイナミックDNSを運用する
IPアドレスを更新するスクリプト
Route53に設定したドメインをスクリプトでDDNS
なお、上記スクリプト実行のためには、下記パッケージを事前にインストールしておく必要がある。(yum installコマンド等)
curl
jq
AWS CLI
その他参考)自分のグローバルIPアドレスを返すサービス(IPv6対応サービスは見つからなかったのが残念)
curl httpbin.org/ip
curl ipinfo.ip

SSL(TLS)通信について

TLSはHTTPSプロトコルやFTPSプロトコルをはじめとした、多くの暗号化通信において、トランスポート層にて利用されている。
今回、太陽光発電のリモコンが集計サーバとうまく通信できていないことの原因を調べるため、RTX1200のポートミラーリング機能を使ってパケットをキャプチャしてみたところ、
Enrypted Alertメッセージがリモコンから集計サーバへの通信時に発生したことを契機にサーバ側から通信が切断(FINフラグが設定)されていることがわかり、原因調査のためにいろんなサイトを探してみた。
Enrypted Alertメッセージが発生した原因は、WiresharkでSSL通信の中身を覗いてみるによれば、Wiresharkにて集計サーバの秘密鍵がないことによって発生しているようで、
なぜうまく通信ができないかの理由にはたどり着けなかったが、よい勉強になったので紹介しておく。
通信できなかった理由については、ミラーリング機能にて取得したポケットを集計サーバの管理会社へ送付し、問い合わせしてみようと思う。
参考サイト
SSL/TLS(Part.1)
HTTPSコネクションの最初の数ミリ秒
SSL Troubleshooting with Wireshark and Tshark (by Sake Blok)

ポート差し込み不良でDestination Host Unreachable

RTX1200でLAN1ポートに刺していたはずの同一セグメントに対するホストにpingを飛ばしたらDestination Host Unreachableが返ってきたという話。
Destination Host Unreachableが返るホスト(IoT機器)から通信テストをしたところルータとの間での通信障害となってしまっており、パケットフィルタリングされているのかとログを調査したが分からなかった。
RTX1200を見てみるとリンクアップしていないような状態だったので、差し込みをしっかり行ったところ通信できるようになった。
変なトラブルに巻き込まれないようにポートへの差し込みはカチッと音がするまで差し込みしましょう。

Zabbixでヤマハルータの温度を取得する

Zabbix温度監視 No.05 SNMPで温度を取得するを参考に
N1200(RTX1200)の温度監視してみることにチャレンジした。
しかし、 No Such Object available on this agent at this OID と怒られて取得に失敗してしまう。
SNMP OID欄にOIDである .1.3.6.1.4.1.1182.2.1.15.0 とすべきところを .1.3.6.1.4.1.1182.2.1.15 としていたことが原因。
代わりに SNMPv2-SMI::enterprises.1182.2.1.15.0 とすることでも正しく取得できる。
OIDは正確に登録しましょう!
$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) .1.3.6.1.4.1.1182.2.1.15
SNMPv2-SMI::enterprises.1182.2.1.15.0 = Gauge32: 44
$ snmpwalk -v 2c -c (コミュニティ名) (IPアドレス) SNMPv2-SMI::enterprises.1182.2.1.15.0
SNMPv2-SMI::enterprises.1182.2.1.15.0 = Gauge32: 44

RTX1200でPPTP接続できない

クラウドサーバから自宅のネットワーク機器を監視するの続編。
WZR-HP-G301NHでPPTPを実現したものの、毎日なぜか切断される事象が発生し、都度クライアント側から接続していた。
今考えれば、MTUの設定値があっていなかったのだろうと推測されるが、当時は、常時接続し続けられるだけのスペックが不足しているのだろうと勝手に考えてしまったことと、SNMPでの状態監視ができないことため、N1200(RTX1200)をネットオークションで落札して試すこととした。
しかし、実際にやってみたところ、Cloudn(PPTPクライアント側とする)とM1200(PPTPサーバ側とする)でPPTPを接続しようとしたがエラーが出てはまった事例。
N1200で表示されたエラーメッセージ
TUNNEL[??] PPTP connection is rejected: (PPTPクライアントのIPアドレス)
結論としては、PPTPはanonymousで登録する必要があり、tunnnelとbindする必要がある。(GUIからは登録できない?)
pp select anonymous
pp bind tunnel1
検証内容
$ pppd debug call (PPTP定義名) updetach
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 ]
anon fatal[open_callmgr:pptp.c:509]: Could not launch call manager after 3 tries.
Script pptp matsuda.biz –nolaunchpppd finished (pid 3100), status = 0x1
Modem hangup
Connection terminated.
PPTPクライアント側でTCPダンプした結果は下記のとおり
$ sudo tcpdump -i eth0 -X port not 22 and host (PPTPサーバ側IPアドレス)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:40:33.989971 IP (PPTPクライアント側IPアドレス).45520 > (PPTPサーバ側IPアドレス).pptp: Flags [S], seq 2347880000, win 29200, options [mss 1460,sackOK,TS val 254809516 ecr 0,nop,wscale 6], length 0
21:40:34.004610 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45520: Flags [S.], seq 2406366252, ack 2347880001, win 65535, options [mss 1414,nop,wscale 1,nop,nop,TS val 25870246 ecr 254809516], length 0
21:40:34.004637 IP (PPTPクライアント側IPアドレス).45520 > (PPTPサーバ側IPアドレス).pptp: Flags [.], ack 1, win 457, options [nop,nop,TS val 254809530 ecr 25870246], length 0
21:40:34.005496 IP (PPTPクライアント側IPアドレス).45520 > (PPTPサーバ側IPアドレス).pptp: Flags [P.], seq 1:157, ack 1, win 457, options [nop,nop,TS val 254809531 ecr 25870246], length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
21:40:34.029304 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45520: Flags [F.], seq 1, ack 157, win 32768, options [nop,nop,TS val 25870248 ecr 254809531], length 0
21:40:34.029583 IP (PPTPクライアント側IPアドレス).45520 > (PPTPサーバ側IPアドレス).pptp: Flags [F.], seq 157, ack 2, win 457, options [nop,nop,TS val 254809555 ecr 25870248], length 0
21:40:34.043614 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45520: Flags [.], ack 158, win 32768, options [nop,nop,TS val 25870249 ecr 254809555], length 0
21:40:35.028270 IP (PPTPクライアント側IPアドレス).45522 > (PPTPサーバ側IPアドレス).pptp: Flags [S], seq 1008276158, win 29200, options [mss 1460,sackOK,TS val 254810554 ecr 0,nop,wscale 6], length 0
21:40:35.042989 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45522: Flags [S.], seq 3144760390, ack 1008276159, win 65535, options [mss 1414,nop,wscale 1,nop,nop,TS val 25870349 ecr 254810554], length 0
21:40:35.043016 IP (PPTPクライアント側IPアドレス).45522 > (PPTPサーバ側IPアドレス).pptp: Flags [.], ack 1, win 457, options [nop,nop,TS val 254810569 ecr 25870349], length 0
21:40:35.044580 IP (PPTPクライアント側IPアドレス).45522 > (PPTPサーバ側IPアドレス).pptp: Flags [P.], seq 1:157, ack 1, win 457, options [nop,nop,TS val 254810570 ecr 25870349], length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
21:40:35.067673 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45522: Flags [F.], seq 1, ack 157, win 32768, options [nop,nop,TS val 25870352 ecr 254810570], length 0
21:40:35.067911 IP (PPTPクライアント側IPアドレス).45522 > (PPTPサーバ側IPアドレス).pptp: Flags [F.], seq 157, ack 2, win 457, options [nop,nop,TS val 254810594 ecr 25870352], length 0
21:40:35.082015 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45522: Flags [.], ack 158, win 32768, options [nop,nop,TS val 25870353 ecr 254810594], length 0
21:40:36.051778 IP (PPTPクライアント側IPアドレス).45524 > (PPTPサーバ側IPアドレス).pptp: Flags [S], seq 1750809907, win 29200, options [mss 1460,sackOK,TS val 254811578 ecr 0,nop,wscale 6], length 0
21:40:36.066305 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45524: Flags [S.], seq 2886155361, ack 1750809908, win 65535, options [mss 1414,nop,wscale 1,nop,nop,TS val 25870452 ecr 254811578], length 0
21:40:36.066339 IP (PPTPクライアント側IPアドレス).45524 > (PPTPサーバ側IPアドレス).pptp: Flags [.], ack 1, win 457, options [nop,nop,TS val 254811592 ecr 25870452], length 0
21:40:36.067176 IP (PPTPクライアント側IPアドレス).45524 > (PPTPサーバ側IPアドレス).pptp: Flags [P.], seq 1:157, ack 1, win 457, options [nop,nop,TS val 254811593 ecr 25870452], length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
21:40:36.090389 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45524: Flags [F.], seq 1, ack 157, win 32768, options [nop,nop,TS val 25870454 ecr 254811593], length 0
21:40:36.090637 IP (PPTPクライアント側IPアドレス).45524 > (PPTPサーバ側IPアドレス).pptp: Flags [.], ack 2, win 457, options [nop,nop,TS val 254811617 ecr 25870454], length 0
21:40:36.090709 IP (PPTPクライアント側IPアドレス).45524 > (PPTPサーバ側IPアドレス).pptp: Flags [F.], seq 157, ack 2, win 457, options [nop,nop,TS val 254811617 ecr 25870454], length 0
21:40:36.105109 IP (PPTPサーバ側IPアドレス).pptp > (PPTPクライアント側IPアドレス).45524: Flags [.], ack 158, win 32768, options [nop,nop,TS val 25870456 ecr 254811617], length 0

クラウドサーバから自宅のネットワーク機器を監視する

自宅のネットワーク機器が正しく動作しているかどうかをチェックするためにWebサーバ死活監視ウィジェットを入れているが、もっと細かく監視したいと思い、クラウドサーバに監視ソフトウエアZabbixをインストールしてVPNで自宅ネットワークに接続しネットワーク機器を監視することとした。
自宅サーバ内にZabbixを入れた方が安全なネットワークを構築できる可能性はあるが、サーバ自体が死んでいては意味がないことと自宅とインターネットとの疎通が取れない場合でも外部からチェックできるようにすることは有用であるとの判断である。
採用したクラウドサービス:GMO Cloud ALTUS(Basic)
ミニサーバのみであれば月額500円で利用できる&通信量による課金が発生しないのがポイント。
採用した仮想マシン:CentOS7
PPTPサーバ:WZR-HP-G301NH
参考サイト:Zabbix 3.0をCentOS 7にインストール
(結果)
参考サイトの通りすんなりZabbix 3.0導入は完了した。Zabbix 2.2よりも使いやすい感じがする。まだ使いこなせてないが・・・・
VPNについてはPPPTPサーバで構築することとしたが下記の通りとなってしまい、なぜがGREパケットが通らず。。。。現在サポート問い合わせ中。
※一部アスタリスクでマスクしています。
# pppd debug call ******* updetach
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 ]
(何回か続く・・・)
sent [LCP ConfReq id=0x1 ]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
Waiting for 1 child processes…
script pptp ******* –nolaunchpppd, pid 1565
Script pptp ******* –nolaunchpppd finished (pid 1565), status = 0x0
—-
14:30 追記
GMOクラウドのサポートセンターより回答あり。Basicシリーズでは対応していないとのこと。。。
残念。。。。Amazon EC2かWindows Azureでやってみることにします。。。
ただ、Zabbix3.0は監視パケットを暗号化できるようになったので、安価な外部監視サーバ導入の目的では上記構成は十分に利用できると思う。

LSW3-GT-5EP おまかせ節電機能 の挙動について

LSW3-GT-5EP を使ってヤマハ AVアンプ RX-V475の音楽を帯域を確保して安定した通信を確保したいと思っていたが、ある時から音楽にノイズが乗るようになり、さらにしばらくするとプレイリストの表示に異常に時間がかかるようになったり、プレイヤーが見つからないという不具合が発生した。
最初はAVアンプ側の不具合かと思ったが、ハブを再起動すると不具合が解消される状態。ランプはリンクアップを表示しているのにプレイヤー側が切断状態になっており、もしかするとおまかせ節電が悪さしているのかもしれない。
おまかせ節電をオフにする方法はないので、再発したら廉価版のハブだけにしょうがないかもしれないと割り切って、GS108E-100JPSに変えてみようかと思う。

Interop Tokyo2014に参加してきました

ネットワークの祭典 Interop Tokyoに初めて参加してきました。
場所は幕張メッセ。いままで千葉にいたときには知らないイベントでしたが、出張ついでに参加することができました。
こういう展示会はよく3年後の未来を先取りできるといわれますが、今回のイベントでは今話題のSDNとその実現方式であるOpenFlowが中心でまさにネットワークのソフトウエア制御による仮想化が主な取り組みだったように感じます。
とはいえ、研究的な取り組みが多く、まだ3年後の未来のキーワードだけが見えて、具体的な実現は皆で考えよーぜ!というような感じだったように思えます。
物理サーバの仮想化は成熟してきていますが、正直ネットワークの仮想化はデータセンタなどでのみ用途があり、一般向けにはまだまだビジネスモデルにつながらないところが本音何だろうと思います。
そもそもなぜネットワークの仮想化が必要になったのかを今回自分なりにまとめてみました。
まずその前にサーバの仮想化はなぜ必要だったのかを整理すると…
1.スケールイン(物理サーバの稼働効率を上げるため)→いわゆるマルチテナント
2.スケールアウトとスケールアップ(仮想マシンをコピーしてサーバの多重度を簡単に上げることや、動的に負荷の高い処理にリソースを割く)
3.ライブマイグレーション(可用性の向上)
の3つだと思います。
星の数ほどあるサービスがほとんどは外れて、一部大当たりして急成長する。昔ならサービスごとにサーバを割り当てるのが当たり前だったけれど、こんなトレンドに迅速に対応するための進化とも言えると思う。
次にネットワークの仮想化の理由を考えてみます。
それは、サーバの仮想化要件に対応するため、スイッチの物理的制約をなくし、ネットワーク機器の柔軟な配置を可能とするためと考えます。
1.可用性をあげる為に構築したメッシュ構造の稼働効率をあげるため。また、そのために犠牲となったMTTRが長くなる問題を向上するため。(STPではMTTRが長すぎる)
2.複数のネットワークで正しい設定を行うことに対する限界(設定ファイルの登録はいまだ人手でやっていることが多いのが現状で、ネットワーク機器の増加に伴い、ヒューマンエラーが課題となっている)
3.ライブマイグレーション実現のためのVLANの進化(現状のVLANでは4096が限界でDCでは運用に耐えられない。またL2ではブロードキャスト通信など無駄なパケットが帯域を圧縮するだけでなく、MACアドレス学習のオーバフローが課題)
これらの課題が、SDNにて解決されることを目指しているわけで、L4~L7を含めオーケストレーションする仕組みで対応するためにOpenFlowの実現方式があります。(今までの仮想化の取り組みは割とL3以下が中心でハードウエアの制御が中心だったと言えると思います)
ただこの取り組みによって何ができるのか?についてはまだ試行錯誤しているように思え、キラーアプリがあれば爆発的に広まるのだろうけれど。。。。という説明された方のぼやきが聞こえてくる一幕もありました。
見ている感じでは、下記のようなものが身近で適用できそうな気がしました。
・特定のポートのQoSを動的に上げることで、無駄なトラフィックの優先度を落とす(業務のネットサーフィンで会社の重要な帯域が占有されることのないようにするなど)
・パケットキャプチャするためにミラーポートを動的に設定し、必要最低限のパケットをコピーしてとりこぼさないようにする(今までは、ミラーポートにつないでいたコンピュータでキャプチャしていたので、帯域幅に対して処理マシンが低いととりこぼししてしまう上に、調査が大変だった)
・セキュリティの向上(FWを動的にフィルタリングしている仕組みをSDNであらゆるネットワーク機器で実現できるようになると、LAN内の通信についても適用することができ、よりセキュリティが高まりやすい)
以上、長文でしたが個人的な感想です。
同時通訳の基調講演も初めて聴くことができ、とても新鮮でした。
もし来年も参加できるようであれば、SDNがどのように進展しているのか、それともバズワードで終わってしまうのか見届けたいと思っています。