なんとなくお蔵入りしてたネタを引っ張りだしてきました。
AzureのVNETと動的ゲートウェイと、AWS上のVyOSなVPNルーターを使ってVPN接続しようというネタです。出来上がる環境はこんな感じ。
IPアドレスとかは例です。あと数か月以上前のネタなのでちょっと変わってる箇所あるかも（VyOSのAMIのバージョンとか）しれませんが適宜読み替えてください。それから簡易な接続なので本運用とかには使わない方がいいかもですね。なんにせよ自己責任で。
VNET
Azure Virtual Network Gatewayの改善
元ネタ：Azure Virtual Network Gateway Improvements
TechEd Europe 2014で仮想ネットワークゲートウェイの改善が発表されました。
- ハイパフォーマンスなゲートウェイSKU
- 仮想ネットワークゲートウェイに関する操作ログの保存
- PFS（Perfect Forward Secrecy：前方秘匿性/将来に向けての機密保護）のサポート
- 暗号化しないS2Sトンネルのサポート
ハイパフォーマンスなゲートウェイSKU
これまでのゲートウェイとの違いは以下の表のような感じです（これまでがDefault）
| SKU | ExpressRouteスループット | S2S VPNスループット | S2S最大トンネル数 |
| Default | ～ 500 Mbps | ～ 80 Mbps | 10 |
| High Performance | ～ 1000 Mbps | ～ 200 Mbps | 30 |
ちなみにお値段も少し違います。（1時間あたり0.49ドル） データ転送料などは同じ。
制限としては静的ルーティングゲートウェイは未サポートで、動的ルーティングゲートウェイとExpressRouteのときだけ使えます。
新規に作ることもできるし、既存のゲートウェイを変更することも可能です。
作り方
新規の時はNew-AzureVNetGatewayコマンドレット（Azure PowerShell）等で –GatewaySKU に指定するだけです。
New-AzureVNetGateway -VNetName MyAzureVNet -GatewayType DynamicRouting -GatewaySKU HighPerformance
HighPerformance か Default を指定します。
既存の変更方法
Resize-AzureVNetGateway コマンドレットで変更します。
Resize-AzureVNetGateway -VNetName MyAzureVNet -GatewaySKU HighPerformance
操作ログ
ゲートウェイの作成や削除、ExpressRouteのサーキット作成・削除・サーキットリンクの認証や作成・削除・BGPセッションの作成・削除・アップデートなどが管理ポータルの操作ログに出力されます。
PFSサポート
PFSはややこしいけど秘密鍵と公開鍵などが漏れてもセッションの機密は保たれる（セッションキーを別で生成するので安全）みたいな鍵交換の方式です。
で、この方式をサポートするので対応する機器であればより安全なセッションを張ることができるでしょうたぶん。
※IPSec（と他一部プロトコル）ぐらいしかサポートしてないので、S2S (VNET to VNET)のみサポートです
暗号化なしS2Sトンネルのサポート
S2Sの接続をする際に、暗号化せずに接続することができるようになりました。一般的にAzure上のVNET同士を接続する場合は比較的安全（盗聴される可能性が一般的なインターネット経由よりかなり低いという意味）なので、パケットの暗号化をしないことでスループットを上げることが可能です。
※On-Premiseとの接続などの場合はやめましょう
Azure 仮想ネットワークでのアドレス空間制限の緩和
17日にアナウンスがありましたが、Azureの仮想ネットワークで設定できるアドレス空間がRFC1918に記載されているプライベート空間以外も指定できるようになりました。
ようは以下の3つのアドレス空間内でやりくりしてねってのが今までです。
- 10.0.0.0 – 10.255.255.255 (10/8 prefix)
- 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
- 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
今後は関係なく設定できるようになったので、より柔軟にネットワークが構成できるかもですね。（IPアドレスは正しく使いましょう）
Azure のネットワークACLの挙動
こういうお話がありました。
結論からいうと、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になったりする可能性があります）
