FortigateVM

FortigateVMは、Fortigate製品の仮想アプライアンスになっているのだが、ちょっと構成が分かりにくい。

技術仕様によれば、モデルによって性能差異が記述されており、製品機能一覧の4ページ目によれば、ハイパバイザーによって利用できる機能は制限されるが、原則的には、FortiOSの機能をすべて利用でき、期待しているスループットが出るかどうかは別として、割と何でもできる万能型のUTMとして使えるように見える。

ところが、下記のようにライセンス形態が構成されており、オプションになっているものがあり、本体(ベース)ライセンスでは、利用できる機能が制限されている。

  • 本体
  • アンチウィルス(オプション)
  • UTMバンドル(オプション)
  • Enterpriseバンドル(オプション)
  • NGFW(オプション)
  • Webフィルタリング(オプション)

本体ライセンスで使用できる範囲がよくわからないので、FortiVMを採用する場合には、よく気をつけた方がよさそうだ。Amazon EC2でも15日間お試しできる(ただし、仮想マシン費用は掛かり、無料枠の対象にはならない)ので、ちょっと調査をしてみようと思う。

参考)株式会社データコントロール社での販売価格表

クラウドサービスで割り当てされるIPアドレス

クラウドサービスで割り当てされるIPアドレスは一度ブラックリストに載っていないかチェックしてから運用した方がよさそう。
前の所有者の悪い行いでブラックリストに登録されていると、メールが届かないとか、いろんなトラブルに巻き込まれそう。。。
TrendMicro
Symantec
ブラックリストのデータベースの信頼性も疑わしい。もう少ししたらレピュテーションサービスの意図的なフォルスポジティブによって、インターネットが支配される日が来るかもしれない。

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

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

AlexaDaysに参加してきました

JWAS-UG金沢のイベントとして、AlexaDaysに参加してきました。
zoomというテレビ会議システム(日本の代理店サイト?はこちら)で全国のJAWSUGの支部と韓国の合計18拠点?で接続していましたが日本語と韓国語の同時通訳とサンフランシスコからの英語セッションもあって、金沢にいても時差を気にしなければ全く問題ない会議が出来ることに衝撃的だった。。。
内容はtwitterで#alexadays で見ることができますよ。
音声がインターフェイスになるというのは人間同士の会話であれば当たり前だけど、コンピューターを通して会話できるということが未来のようですぐそこにまできているということがよくわかった。
ニュース記事
JAWS-UG15支部と韓国のAWSKRUGが「Alexa Days」を共同開催
YouTubeの映像
Echo Dotを音声コントロール(Amazon Alexa)-AV Watch
アマゾンエコーはあらたなる購買形式に成り得るか?使用感と将来性をレポート!
[English Sub] 話題のAmazon Echo 紹介!/ Introducing…

CloudFrontを利用して静的コンテンツを高速化する

このブログサイトをCloudFrontを使って高速化してみた。
早くなったかどうかはちょっとわからないが、Googleからのリクエスト速度は間違いなく上がっているので、検索順位向上には寄与している(と思いたい)。
CloudFrontはCDN(Content Delivery Network)のサービスだが、EC2やLamdaなどのAWSのサービス以外にも利用できる。
昔はCDNなんてakamaiぐらいしかなく、個人が使えるようなサービスではなかった。
CloudFrontを独自ドメインで利用するメリットは下記が挙げられる。
1.全世界からのアクセスが高速化できる。(CDNの導入目的と同じ)
例えば、当ブログサイトのドメインに割り当てられているアドレスd2p33equgohrri.cloudfront.netを正引きすると以下のように8つのアドレスが返される。
このアドレスは、リクエスト元の地域(リージョン)によって変わることになる。
>nslookup -q=A d2p33equgohrri.cloudfront.net
権限のない回答:
名前: d2p33equgohrri.cloudfront.net
Addresses: 54.230.111.20
54.230.111.187
54.230.111.227
54.230.111.55
54.230.111.251
54.230.111.57
54.230.111.220
54.230.111.238
2.Webサーバへのリクエストを減らすことが出来る=負荷を軽減できる。(CDNの導入目的と同じ)
3.(D)Dos攻撃にも耐えられる。(CDNの導入目的と同じ/但し、リクエスト数が増大するので、課金がかさむことになる)
4.CloudFrontをSSL化しておいて、CloudFront→Webサーバ 間をHTTP通信にすることにより、昨今のセキュリティ要求に対応しながら、SSL通信にかかる負荷を軽減できる。
5.SSL証明書が無料で利用できる(CloudFront独自のメリット/但し、IPベースにすると毎月600ドル課金されるので注意)
6.AWSの無料枠の対象なので、気軽に試せる(CloudFront独自のメリット)
7.HTTP/2に対応できる。(CloudFront独自のメリット?/リクエストが高速になる)
SSL証明書はLet’s Encryptを利用する方法もあるが、CloudFrontを利用すると証明書の期限が13ヵ月になっているうえ、更新が自動で行われる点がビジネス目的に耐えられる点で優れている。
CloudFrontを利用するにはWebの画面だけで完結できるが、日本語化されておらず少しハードルは高い。
ただ、WordPressサイトをCloudFrontで配信するの説明が非常に分かりやすい。
上記サイトでは、WordPressサイトの登録を変更していたが、
Origin Domain Name には、CDN用のエイリアスFQDN(例:cdn.blog.development-network.net)
Alternate Domain Names には、オリジナルのFQDN(例:blog.development-network.net)
を登録し、cdn.blog.development-network.netのCNAMEに登録後に表示されるDomain Name(例:d2p33equgohrri.cloudfront.net)をDNSに登録すればよい。
SSL証明書の発行手順は、認証がメールベースになっているので、独自ドメインのメールエイリアスを登録できるようになっている必要がある。
SSL証明書を発行しても、すぐに独自ドメイン用のSSL証明書に切り替わらず、証明書エラーが表示されるので、少し焦るがCloudFrontのStatusがDeployedになるまでは待ってみることをお勧めする(焦った)

JAZUG北陸に参加してきました

JAZUG北陸に参加してきました。
参加して身についたこと
・ラズパイでブレッドボード上にセンサーを取り付ける時には、配置をしっかり考えないと配線だらけになってしまう問題があるということ。
 復元する意味でも、しっかり設計図は残しておこう。
・LEDの調光などはオン、オフの時間を調整することで実現しているという話
・MySQLやPostgreSQLのサービスは、対応するプラグインサービスがあり、DaaSがAzure等で利用できるということ
・クラウドと言っても開発環境はやはりローカルで保有しないと開発効率が悪い
・チーム開発する場合においては、ローカル環境を同期して最新化する必要があるので、その意味でもWindows OSでは厳しいのではないか?
・Gitでバイナリデータを管理する方法
・Herokuでの開発スタイルは身に着けてみた方がよい。
 →Oracle Meetup@北陸 AIが入ったBotの作り方を学ぼうを参考
発表したこと
Azure DNSではなくRoute 53でDDNSを構築しました

AzureDNS

先日AWSのDNSサービスを利用したmydnsからroute53へ移行するを紹介したが、Windows AzureでもAzure DNSがあるようだ。
価格を見ると、AWSとほぼ変わらないか、少し高い感じがする。
ところで2/11からzaiteku.jpドメインをroute53へ移行した金額を下記に公開する。
現時点では、mydnsと2重化している(下記Whois情報参考)ので、4/6のクエリになっていると推測される。
請求金額
請求明細.jpg
参考)Whois情報
$ whois zaiteku.jp
[ JPRS database provides information on network administration. Its use is ]
[ restricted to network administration purposes. For further information, ]
[ use ‘whois -h whois.jprs.jp help’. To suppress Japanese output, add’/e’ ]
[ at the end of command, e.g. ‘whois -h whois.jprs.jp xxx/e’. ]
Domain Information: [ドメイン情報]
[Domain Name] ZAITEKU.JP
[登録者名] Development Network
[Registrant] Development Network
[Name Server] ns-1447.awsdns-52.org
[Name Server] ns-2016.awsdns-60.co.uk
[Name Server] ns-229.awsdns-28.com
[Name Server] ns-925.awsdns-51.net
[Name Server] ns0.mydns.jp
[Name Server] ns1.mydns.jp

AzureDNS

先日AWSのDNSサービスを利用したmydnsからroute53へ移行するを紹介したが、Windows AzureでもAzure DNSがあるようだ。
価格を見ると、AWSとほぼ変わらないか、少し高い感じがする。
ところで2/11からzaiteku.jpドメインをroute53へ移行した金額を下記に公開する。
現時点では、mydnsと2重化している(下記Whois情報参考)ので、4/6のクエリになっていると推測される。
請求金額
表示
参考)Whois情報

$ whois zaiteku.jp
[ JPRS database provides information on network administration. Its use is    ]
[ restricted to network administration purposes. For further information,     ]
[ use 'whois -h whois.jprs.jp help'. To suppress Japanese output, add'/e'     ]
[ at the end of command, e.g. 'whois -h whois.jprs.jp xxx/e'.                 ]
Domain Information: [ドメイン情報]
[Domain Name]                   ZAITEKU.JP
[登録者名]                      Development Network
[Registrant]                    Development Network
[Name Server]                   ns-1447.awsdns-52.org
[Name Server]                   ns-2016.awsdns-60.co.uk
[Name Server]                   ns-229.awsdns-28.com
[Name Server]                   ns-925.awsdns-51.net
[Name Server]                   ns0.mydns.jp
[Name Server]                   ns1.mydns.jp

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