- IIJと日本マイクロソフト、マルチクラウドサービスで協業 (Microsoft)
- IIJと日本マイクロソフト、マルチクラウドサービスで協業 (IIJ)
早い話がAzure ExpressRouteの日本国内対応ベンダーの一社目がIIJさんになりましたというNewsです。
対応時期は今年度順次対応予定ということですが、閉域網接続を望んでた企業にとっては朗報ですね。
ま、検証しようがないので中の人や興味ある人は頑張って試してみてください~☆
早い話がAzure ExpressRouteの日本国内対応ベンダーの一社目がIIJさんになりましたというNewsです。
対応時期は今年度順次対応予定ということですが、閉域網接続を望んでた企業にとっては朗報ですね。
ま、検証しようがないので中の人や興味ある人は頑張って試してみてください~☆
Internal Load Balancing(内部向け負荷分散)がGA(一般提供)されました。
はやかったですね。ご利用はAzure PowerShell等でどうぞ。
受賞できました。4年目です。
また1年間いろいろがんばりたいと思います。
※ Windows Azure から Microsoft Azureになりましたねそういえば。
こういうお話がありました。
結論からいうと、LBとかじゃなくてホストサーバー上の設定なのでVNET(特に拒否の設定)指定ができちゃいます。
とはいえちょっと気になったので見てみることにします。こんなVNET to VNETなネットワークをAzure上で組んでみました。
ca1-srv1-vnet1 なインスタンスにIISを入れてHTTP(tcp/80)なエンドポイントを定義します。(LBは省略しました)
ネットワークACL(エンドポイントACL)を何も設定しない際に各インスタンスで内部のIPアドレスと外部のFQDN(図だとca1.cloudapp.net)にブラウザで接続してIISの既定のページが見れることは確認済みな状態とします。(Azure外のクライアントも当然OK)
※ようは疎通できてる状態
さて、以下の表のような感じでACLを定義したときに、それぞれのインスタンスから内部IPとFQDNでアクセスしてどうなるかを見てみました。
| ACLの状態 | ca1-srv1-vnet1 | ca1-srv2-vnet1 | ca2-src1-vnet1 | ca3-srv1-vnet2 | 外部PC | ||||
| 内部IP | FQDN | 内部IP | FQDN | 内部IP | FQDN | 内部IP | FQDN | FQDN | |
| vnet1のみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| vnet1のみ拒否 | OK | OK | NG | OK | NG | OK | OK | OK | OK |
| vnet2のみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| vnet2のみ拒否 | OK | OK | OK | OK | OK | OK | NG | OK | OK |
| 外部PCのみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | OK |
| 外部PCのみ拒否 | OK | OK | OK | OK | OK | OK | OK | OK | NG |
| ca1のGIPのみ許可 | OK | OK | OK | OK | OK | NG | OK | NG | NG |
| ca1のGIPのみ拒否 | OK | NG | OK | NG | OK | OK | OK | OK | NG |
| ca2のGIPのみ許可 | OK | OK | OK | OK | OK | OK | OK | NG | NG |
| ca2のGIPのみ拒否 | OK | OK | OK | OK | OK | NG | OK | OK | OK |
| ca3のGIPのみ許可 | OK | OK | OK | OK | OK | NG | OK | OK | NG |
| ca3のGIPのみ拒否 | OK | OK | OK | OK | OK | OK | OK | NG | OK |
※クラウドサービスのグローバルIPアドレスは一応インスタンス上からインターネットにアクセスした際に使用されるIPアドレスを確認して設定
本来ネットワークACLは許可だけが設定されたらそのルールにマッチしないものは拒否になるはずですが、VNETを許可した場合はその辺うまく動作してない様子。
例えばvnet1だけ許可した場合だと、vnet2にいるインスタンスからもアクセスできてしまっています。(期待値としては拒否してほしい)
ただ拒否設定の場合は想定どおりになるようなので、何とも不可思議な挙動です。(表中で怪しいところをわかりやすくしようと思ったけど、面倒くさくなったので放置)
但し、ネットワークACLのドキュメントを見る限りでは
仮想ネットワークに対して ACL を指定したり、仮想ネットワーク内にある特定のサブネットに対して ACL を指定したりすることはできません。
とあるので今のところこのあたりの挙動は想定外なのかもです。今後に期待。
また、ネットワークACLのパケットフィルタ処理はホストノード上で実行されるようです。
ACL を作成して仮想マシンのエンドポイントに適用するとき、パケット フィルターが VM のホスト ノードで実行されます。これは、リモート IP アドレスからのトラフィックのフィルター処理が、VM 上ではなく、ホスト ノードによって実行され、ACL ルールとの照合が行われることを意味します。これにより、パケット フィルターの処理で VM が重要な CPU サイクルを消費するのを防ぐことができます。
上位のFWとかルータじゃなかったのねー。
まぁとりあえず現状はVNETに対するACLは微妙にノンサポートという感じですので、もし制限したい場合はご注意ください。(意図せず外部はOKになったりする可能性があります)
Updateはいつも唐突に。
というわけで現行ポータルでWebサイトにアクセスするとこんなメッセージがでるようになりました。
Oh…
今回のUpdate内容も基本はプレビューポータルでの話ですね。
元ネタはこちら
思うに、秘密鍵へのアクセスが制限されてるからな気がする。
実際に証明書をインポートして、Certmgrとかからエクスポートしようとしても秘密鍵のエクスポートが許可されてないのでアクセスできません。
Azure上で動かないのは下記のKBあたりが原因かな?
アプリケーションプールの実行ユーザーに適切な権限が無かったりユーザープロファイルがロードされてないのが原因ぽいです? 秘密鍵にコードからアクセスできないからそこは良しなにしようとするけど、それもできずに例外吐いてるのかなー。
とか思いました。Webサイトじゃなくてクラウドサービスならあるいは。
まぁPublishSettingsの中の証明書が変わるかしないとしんどいかな。しかしアレはアレで面倒なのでどっちつかずであります。
Azureの新しいデータセンターとしてブラジル南部リージョンがGAしました。
いつの間にか文字化けも直ってますね。。
というわけで、どんどんDCが増えますね。まぁDC増えるのもいいのですが、全リージョンで機能レベルを合わせてほしいです。。。
追記:ブラジルGEOとしてはブラジル南部(サンパウロ)と、現状は米国中南部(テキサス)への片方向レプリケーションのようです。(Microsoft Azure のトラスト センター)
※あと、このあたりの影響かどうかはわかりませんが、アメリカ中北部とかのIPアドレスの所在地がブラジルにあると認識されちゃったりするっぽい?のでSR投げるかしてあげると良いのではないでしょうか。
※経路が腐ってたり、TrafficManagerがおかしな挙動するとかだと大変アレです。
いわゆるMicrosoftさんが出してる自習書なるドキュメントです。ハンズオン形式で自分で試しながら勉強できます。
中身はこんな感じです。
ダウンロードサイトからゲットしてください。(諸般の事情により個別にダウンロードとなるようです)
とりあえず//Build/あたりのUpdateは最低限入ってると思われます。TechEd 2014 NAはどうだったかな?
Webサイトとかは更新が早いのでなかなか。あと今の一覧見て分かる通り、どちらかというとエンタープライズ向けです。(企業向け)
したようです。
Hadoop Summitで発表があったみたいですね。
詳細はこちら
ってされてるんですか?という話題があったので適当に見てみました。
EICARテストファイルを作ってどんな挙動になるかというのを見てみます。
こんな感じでWebサイト上に作ります
そもそも普通に作成できました。実行してみましょう。
普通に実行できました。まぁ実際に動作するファイルじゃないわけで結果は妥当な感じ。(アンチウィルスのチェックとしてはダメですが)
さてローカルPCで見てみましょう。
中身を入力して保存したタイミングでWindows Defenderさんが反応します。
実行するとちゃんとウィルスの可能性があるから実行しないよ的なメッセージになります。
しばやん先生によるとAzure Webサイト上はWindows Defenderが手動開始になっているようで、動作してないっぽいですね。
というわけで注意しましょう。