【Azure】ポイント対サイト接続がとても便利!

Azureの仮想マシンを利用していると、サーバ自体にログインして作業したいことがしばしばあります。 もちろん仮想マシンに付与されているグローバルIPアドレスを使用してアクセスすることもできるのですが、 特定のIPアドレスからのみのアクセスを許可するようNSGでアクセス元のIPアドレスを制限してセキュリティを高める必要があります。

そこでポイント対サイト接続です!!!
Azureのポイント対サイト接続は以下の方にオススメです!!!

  • NSGグローバルIP向けのメンテナンス通信を許可したくない
  • Windows 8以降のクライアント端末を使用している


<目次>



そもそもポイント対サイト接続とは

ポイント対サイト接続とは、クライアント端末からAzureの仮想ネットワークにVPN接続をすることができるサービスです。 これにより、クライアント端末はAzureの仮想ネットワーク内にいることになるので、仮想ネットワーク内のサーバにプライベートIPアドレスで接続することができます。
以下のようなイメージです。

f:id:hayato320:20161210152810j:plain

プライベートIPアドレスでの接続になるので、NSGで接続元のIPアドレスを制限する必要もありません。

ただし、注意が必要なのはポイント対サイト接続が利用できるのはWindows 8Windows Server 2012Windows 10Windows Server 2016のみになります!!!!
本当に残念ながら私の愛おしいMacではポイント対サイト接続を利用することができません。。。

ポイント対サイト設定方法

基本的にはMSの公式ドキュメントに記載があるので、それに従ってインストールしていきます。

docs.microsoft.com

ここでは具体的な設定方法は省略いたしますが、ざっくりと以下のフローになります。

  • 仮想ネットワークの作成(すでに作成済みなら不要)
  • VPNゲートウェイ作成
  • 証明書の生成、インポート
  • 実際の接続

かなり簡単にできちゃいます。
なお、証明書周りが個人的にハマりポイントだったので、補足いたします。 VPNゲートウェイにアップロードする証明書は、WIndows SDKが入っていればmakecertコマンドがあるディレクトリに移動して、以下のコマンドで作成することができます。

\makecert.exe -sky exchange -r -n "CN=enjoymylifeRoot" -pe -a sha1 -len 2048 -ss My "enjoymylifeRoot.cer"


ポイント対サイト接続をするクライアントPCでは、上記のRoot証明書で信頼されているクライアント証明書を利用します。
以下のコマンドで生成可能です。

.\makecert.exe -n "CN=enjoymylifeClient" -pe -sky exchange -m 96 -ss My -in "enjoymylifeRoot" -is my -a sha1


上記のクライアント証明書が証明書ストアにインストールされていれば、パスワードなしでAzureの仮想ネットワーク内に接続することができます。


ポイント対サイト接続料金

ポイント対サイト接続の料金は、VPNゲートウェイ自体の料金とVPNゲートウェイから外部への転送データ料金に基づきます。
簡単な開発をするだけならBasicで十分なので、1ヶ月3,000円くらいとお安く利用できます。
詳細は料金は以下を参照してください。

azure.microsoft.com

まとめ

ポイント対サイト接続はとても簡単に設定でき、セキュリティ面を向上させることができます!(NSGで穴あけをしないので)
BasicのVPNゲートウェイを利用すれば 1ヶ月3,000円くらいで利用できるので、Windows 8 以降のクライアント端末を使って開発している人にはとてもオススメです!

iPhone歴7年の筆者がiPhone 7をオススメするたった一つの理由

こんにちは。
iPhone 7が発売されてからもうすぐ2ヶ月が経ちますね。
iPhone 7のエントリーは大分出たかとは思いますが、iPhone歴7年の筆者がiPhone 7を2ヶ月使用してみて感じた iPhone 7をオススメするたった一つの理由をお伝えしたいと思います。

モバイルSuicaが使える

もうこれに尽きます。
というかこれしかないです。
iPhoneの欠点として、定期等の利用でSuicaが手放せないにもかかわらず、モバイルSuicaが使えないことでした。
筆者はSuicaを入れられるケースを使用してSuicaをモバイルしていました。

モバイルSuicaが使えると何が良いの!?

通常Suicaにクレジットカードを使用してチャージをしようと思うと、VIEWマークが付いているクレジットカードじゃないとできないんです。
つまりポイント還元率が高いみんなが普段使用しているカードが使えない。
そうすると例えばコンビニ等で支払う時はクレジットカードを財布から出して決済する必要があります。ポイント貯めたいですもんね。
でもiPhone 7のモバイルSuicaではVIEWマークが付いていないクレジットカードでもオンラインでチャージができるのです!!
つまり普段ポイントを貯めているカードでSuicaにチャージができるのです!!
これは本当に嬉しいですよ!!
しかもAndroidモバイルSuicaをやる際に、VIEWカード以外でチャージするには年会費1,030円かかります。 iPhone 7だとこれが0円。めちゃめちゃ良いですよね!みんなAndroidからiPhoneにするべきです。

まとめ

iPhone 7のモバイルSuicaは年会費無料ですきなカードを使用してチャージができます。
日本に住む皆さんにiPhone 7をお勧めします!

Kindleで購入した本がiPhoneで表示されない場合の対処法

新しいガジェットが大好きな筆者は9月にiPhone SEからiPhone7に変えました。
バックアップはパソコンに取っており問題なく復元できたのですが Kindleだけ復元が上手くいかず時間がかかってしまったのでその解決方法を残しておきたいと思います。

以下の方向けの記事です。


Kindleで購入したはずの本が表示されない。

iPhoneのバックアップはパソコンに取っています。 復元は問題なくできました。 iPhoneをバックアップから復元してもアプリケーションの同期はできていないので、 改めてアプリケーションの同期を行う必要があります。
ほとんどのアプリケーションは問題ありませんでしたがKindleアプリの同期で 問題が発生しました。
同期はエラーなくできたのに、なぜか購入したはずの表示されないのです。
代わりに購入した記憶がない英語の本が表示されていました。

f:id:hayato320:20161106150118p:plain:w300



原因はAmazonアカウントを複数保有していること

調べてみると日本アマゾン(amazon.co.jp)と米国アマゾン(amazon.com)の両方のアカウントを同じメールアドレスで保有していました。 (パスワードも同じ(笑))
アカウントを両方保有していることがわかってから、米国アマゾンの方に同期されているのでは?? と考えました。
米国アマゾンで購入した本と登録されている端末は以下で確認できますが、確認したところ米国アマゾンのアカウントに端末が登録されていました。

https://www.amazon.com/mn/dcw/myx.html#/home/content/booksAll/dateDsc/

なぜ米国アマゾンアカウントに同期されたのか

筆者のiPhoneのiOSの言語設定が英語になっています。
KindleのアプリケーションはiOSの言語設定からKindleの同期先を選んでいるようです。
一度アプリケーション上でログアウトしてから、iOSの言語設定を日本語に戻して再度アプリでログインをすると 問題なく購入した本が表示されるようになりました。
その後iOSの言語設定を英語に戻しました。


まとめ

iPhoneの買い替えを行なった後にKindleが同期できているのにもかかわらず 購入した本が表示されない場合は、一度アプリからログアウトして、 iOSの言語設定を日本語にした後に再度ログインしましょう。
iOSの言語設定を英語にすることを忘れずに。

【Azure】VNETピアリングとVNET-to-VNETの比較

VNETピアリングが2016年9月28日にGAされました。

元々AzureではVNET-to-VNETで仮想ネットワーク同士の接続をすることが出来ましたが、VNETピアリングの登場により 仮想ネットワーク同士の接続の選択肢が増えました。
今回はVNET-to-VNETの振り返りと、VNETピアリングによって何が出来るの?どっち使うが良いの?というところをまとめたいと思います。


VNET-to-VNET

概要

サブスクリプションでも異なるサブスクリプションでも同じリージョン内なら仮想ネットワークを接続することができます。
異なるリージョン同士でも仮想ネットワークを接続することができます。
AWSVPCピアリングは異なるリージョンでは接続できないので、これはAzureが有利ですね。)

通信はAzureのバックボーンを使用するのでインターネットには出ません。 インターネットに通信が出るというと、よく分からないけど怖いという人がいますが、その点VNET-to-VNETは大丈夫です。

公式のドキュメントはこちら。
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-configure-vnet-to-vnet-connection/

料金

VPN Gateway自体に料金かかるのとVNET間同士のトラフィックに対して料金が発生します。 VPN GatewayをStandard Gateway、リージョンを東日本リージョンと仮定した場合以下の料金になります。

料金
VPN Gateway(Standard Gateway) ¥19.38/時間
VNET 間送信データ転送 ¥9.18/GB



VNETピアリング

概要

VNETピアリングは異なるサブスクリプション同士の接続はできますが、異なるリージョン同士の接続は許されておりません。
VNET-to-VNETに比べて遅延が少なく、価格が安いのがメリットです。

公式ドキュメントはこちら。
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-network-peering-overview/ https://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-create-vnetpeering-arm-portal/

料金

VNETピアリング自体に料金はかからないようですが、受信と送信のトラフィックに料金がかかります。

料金
受信データ転送 ¥1.02/GB
送信データ転送 ¥1.02/GB

VNET-to-VNETに比べると安いですね。



まとめ

同リージョン同士の接続の場合にはVNETピアリングの方が料金が安いですし、遅延が少ないため良さそうです。
同リージョン同士の接続の場合はVNETピアリング、異なるリージョン同士の接続の場合はVNET-to-VNETで接続するという整理が良さそうです。

【Azure】Sorryサーバを構成する

オンプレミス環境でWebサーバを構築している際にLoad Balancerを使用して負荷分散することは一般的かと思います。
その際、LBではWebサーバがダウンしている場合や一定のセッション数以上になった場合に振り分け先をSorryサーバにするということはよくあるケースです。
そのような構成をオンプレミス環境からAzureに持って行く際に、Sorryサーバに振り分けってどうやるの?ということを調べたのでまとめておきたいと思います。


オンプレミス環境での構成

Webサーバが3台あり全てのサーバの異常時にSorryサーバに振り分けを行います。 オンプレミス環境では下記のような構成です。

f:id:hayato320:20161030224341j:plain



Azureでの構成

単純にAzure Load BalancerでWebサーバがダウン時にSorryサーバに振り分けばいいじゃんと思うかもしれないですが、Azure Load Balancerにそのような機能はありません。
なので他のサービスと組み合わせる必要があります。
Azureには負荷分散の機能として下記のサービスがあります。

  1. Traffic Manager
  2. Azure Load Balancer
  3. Application Gateway

2のLoad Balancerと3のApplication GatewayにはWebサーバ異常時にSorryサーバに振り分けるような機能はありません。
一方でTraffic Managerには優先度に応じて振り分け先を順に評価して行く機能があります。
この機能を使用してWebサーバが異常時にSorryサーバへの振り分けを実現します。

ただし気をつけなければならないのが、Traffic ManagerはDNSレベルでの動作なので、Cookieを含めたクライアントとサーバ間のHTTPトラフィックは把握されません。 セッションパーシステンスが必要ならやはりLBを使用する必要があります。

以上から、以下のような構成で実現するのが良さそうです。

f:id:hayato320:20161030224346j:plain

※Azure Load BalancerはApplication Gatewayに置き換え可能です。



まとめ

AzureでSorryサーバを構成する場合、Traffic ManagerとAzure Load Balancer(もしくはApplication Gateway)を使用するのが良さそうです。
上記の方法以外にもWebサーバの前にnginxを使用したProxyサーバを立ててSorryページを表示することなどもできるので、何がやりたいかによって実現する方法は変わるかと思います。
AzureでSorryページを表示する一例として捉えていただければと思います。